Я долго откладывал написание этого поста, но время пришло. Если вы являетесь начинающим разработчиком и выбрали MODx (как и я много лет назад) в качестве основного фреймворка для своей разработки, то вы должны знать несколько достаточно неприятных фактов об этой системе. Надеюсь, что они заставят вас задуматься.

Дошли руки доработать компонент NotFoundParamAlert, позволяющей отлавливать несуществующие страницы с заданными GET параметрами. Лично я его использую для раннего выявления ошибочно настроенных объявлений в контекстной рекламе, отлавливая такие объявления по UTM меткам. Однако никто не мешает отлавливать все ошибочные страницы с GET параметрами задав в качестве правила просто *.

В очередной раз замучавшись объяснять на одном из проектов, что в момент создания документа необходимо проверять назначаемый шаблон вновь создаваемому документу, решил написать костыль. Сначала коснемся сути проблемы, а потом разберем получившееся дополнение.

Как многие знают, парсер MODX Revolution при работе с модификаторами, имеет одну неприятную особенность, которая иногда сводит на нет их применение. Проблема в том, что при использовании условных модификаторов типа выполнить_что_либо команда находящаяся в условии будет обработана парсером, вне зависимости от того, истинно оно или ложно. В очередной раз намучавшись с данной проблемой, решил попробовать ее решить. Дисклеймер, будет много букв.

Пришла в голову разработка одного компонента для MODX Revolution. Выяснилось, что для его разработки надо хорошо понимать процесс того, как работает данная CMS и как она обрабатывает запросы к сайту. Предлагаю подробно рассмотреть и попытаться разобраться, как происходит обработка входящих запросов в MODX Revolution.

В очередной раз на крупном клиентском проекте, где настроены все виды контекста, обнаружил, что опять была изменена структура сайта и часть объявлений стала вести на несуществующие страницы. И если Google Adwords об этом хотя бы честно предупреждает, хоть и не сразу, то Яндекс Директ молчит как партизан. В общем решил, что надо разобраться с этим вопросом.

Праздники это прекрасное время позаниматься какой-нибудь фигней, например, наконец-то реализовать идею автоматической очистки кода PHP файлов при выкладке в продакшн. Очистку будем осуществлять средствами Gulp, так как эту библиотеку все равно регулярно использую для мелкой автоматизации. Но начнем с самого начала.

В предновогодней суете хотелось бы в очередной раз коснуться вопроса разработки с PHPUnit. На этот раз речь пойдет об использовании наборов данных (на языке PHPUnit они называются дата провайдеры) для автоматических тестов. Почему захотелось написать именно про наборы, потому что это не часто используемая техника позволяет существенно сократить код тестов и сделать их более наглядными.