Были описаны два способа (хотя формально делегированием называется способ, использующий NS-записи). Какой не работает? Делегирование может занимать до нескольких суток. Активизация A-записи тоже может происходить не мгновенно.
У многих провайдеров при добавлении домена 3-го уровня и сайта на таком домене нужно сначала добавить соответствующий домен 2-го уровня. Ничего что этот домен 2-го уровня и сайт на нем размещены на другом (DNS-)хостинге.
Не забудьте, что при делегировании нужно указывать минимум две записи с разными значениями (именами DNS-серверов), например:
subdomain NS ns1.estic.ru. 21600
subdomain NS ns2.estic.ru. 21600
(21600 - это пример значения TTL, если нужно).
Смотря по тому, какова цель.
Может. Тогда это тоже обработчик.
Т.е. достигнуть "цель обработки" можно при помощи любого метода запроса? Можно выбрать любой метод?
Метод класса, обычная или анонимная функция и т.д. Т.е. то что вызывается в маршрутизаторе при маршрутизации, но не относится непосредственно к нему.
Правильно ли я понял, что с вашей точки зрения можно любые действия "повесить" на GET?
В смысле один обработчик на один адрес (адреса одного формата)? И не более одного?
Вы серьезно? Это распространенная практика. Для приверженцев REST - вовсе "норма жизни".
Обработчик делается исходя из целей обработки, а не исходя из метода запроса.
Т.е. любой обработчик можно "повесить" на любой метод и будет нормально? 😊
Выше уточнил. Смысл был в том, что общий обработчик может быть связан с GET чисто формально по имени, а не быть каким-нибудь специальным default, special, etc.
Что используется узкоспециализированный обработчик для GET, как общий. Хотел даже написать "для GET".
В маршруте можно хранить признак: "сливать" запросы любыми методами в общий обработчик (который может быть связан с GET чисто формально, например метод класса может называться соответствующим образом) или делать дополнительную маршрутизацию по методу запроса в рамках текущего "адресного" маршрута. Т.е. можно выбирать стратегию индивидуально для каждого маршрута.
Правильно, если речь об обработке. Более того, лучше не использовать отдельные адреса для обработки POST-запросов (и др.). Т.е. физически можно использовать один маршрут для одного формата адресов и разных методов запроса. Основные стратегии, которые могут быть реализованы в одном и том же маршрутизаторе для одного формата адресов: 1) использовать общий обработчик для разных методов, "от GET" или специальный; 2) использовать отдельные обработчики для предопределенных методов, а для "неопределенных" - специальный или "системный", который бы сообщал, что "метод не поддерживается" (для этого есть специальный HTTP-код ответа).
Можно использовать упрощенную реализацию только для GET/POST. Это связано с ограничениями браузеров, когда не используется AJAX, и самого PHP. Без специальных расширений PHP, например, не различает PUT- и PATCH-параметры.
Так лом можно было использовать?
В таком случае можно было и молотком, топором или лопатой "решить проблему" 😀
По большому счету здесь даже для catid не нужен подготовленный запрос, т.к. существование категории должно проверяться отдельным "опережающим" запросом. Иногда используют и "ленивые" проверки, но не думаю, что автор достиг такого уровня.
