Для разработчиков

Одна из проблем развития экосистемы MODX3 на текущий день — не очень большой объем доступной информации, инструкций. Официальный сайт только недавно начал выпускать справочные пособия на тему разработки MODX3.

Мне в свое время очень помогла в понимании работы компонентов, подготовленная @Василий Наумкин заготовка для создания компонентов modExtra. Я решил поднять это знамя и донести его до MODX3

Представляю вашему вниманию ModExtra3. Заготовка для создания компонентов и справочное пособие по MODX3.

Третьего дня Сергей Шлоков провёл новый тест скорости работы парсера MODX и шаблонизаторов Fenom и Smarty.

До Smarty мне дела нет, но с итоговыми выводами, что никакой разницы в скорости между синтаксисом MODX и Fenom не видно, я категорически не согласен.



Итак, что нужно прояснить. У оригинального парсера MODX modParser есть две, на мой взгляд, фундаментальные проблемы:

Во-первых, каждый тег при разборе превращается в PHP объект modTag и в нём запускается метод process. То есть, если в чанке указан просто [[+id]], то MODX вместо обычной замены его через str_replace будет создавать новый объект и парсить.

Во-вторых, из-за своей рекурсивной природы, MODX выполняет все условия в чанках. Он просто не знает, во что могут превратиться эти условия на пятой, например, итерации. Причём делает он это изнутри наружу.
То есть, если вы прячете какой-то кусок оформления для вывода только нужным пользователям за условиями в чанке — именно этот кусок и будет первым делом разобран, а потом MODX решит, нужно ли его выводить, когда проверит условие с юзером. Народ придумывает разные костыли для обхода этого момента, чтобы парсить только нужное, типа [[![[+user:is=`admin`:then=`auth`:else=`guest`]]]].

В очередной раз прочитав утверждение, что Fenom быстрее стандартного парсера, решил провести указанный в документации pdoTools тест, чтобы расставить все точки над и. Но решил сделать это не отдельными скриптами, как в документации, а практичнее — через сниппет, который будет вызыватся на странице. Плюс добавил для сравнения шаблонизатор Smarty из ZoomX. Так вот, у меня таки есть шо вам сказать.

ZoomX постепенно начинает набирать популярность. В связи с чем возникает ряд вопросов. Один из которых — кэширование элементов в шаблонизаторе Smarty. В принципе, по документации не сложно разобраться. Но, конечно, модыксерам хотелось бы работать так, как они привыкли. В этом плане Fenom из pdoTools реализован именно по этому принципу — для запрета кэширования в названии элемента указывается восклицательный знак. Всё привычно. Но работает не всегда.

Перевод заметки Using MODX Outside of MODX3

В одной из статей было рассмотрено создание экземпляра объекта $modx в эпоху до MODX3. В этой статье мы рассмотрим использование MODX вне MODX Revolution 3. Большая часть кода такая же, как и в предыдущей статье (прим. переводчика: предыдущая статья не переведена, так как немного не актуальна в рамках перехода на модх3). Основное отличие состоит в том, что MODX Revolution 3 широко использует пространства имен и имеет автозагрузчик для загрузки классов.

Приветствую, довольно часто приходят клиенты с просьбой внести какие-то правки на сайте, и бывает так, что fenom на страницах не используется, а я привык, он удобные. Иду тогда в настройки и включаю. После этого сайт перестает отображаться, вместо страниц белый экран. Надо включать сохранение ошибок и искать, где есть открывающая фигурная скобка и ставить после неё пробел. Хорошо, если это только код метрики в шапке, но бывают запущенные случаи, тогда проще написать небольшой скрипт. Собственно его и выкладываю. Он простой, но скопировать готовое всегда проще)))

Это вводная статья для серии публикаций, посвященного удобному построению полноценного RESTfull API для любых целей.

Ребят, вы меня наверняка знаете, как человека, который много времени потратил на улучшение MODX. Список моих выступлений вот тут, но список заслуг на это не заканчивается. Тем не менее, все это время я работал в разных компаниях и проектах, а последнее время и вовсе стал руководить целыми командами разработчиков.

Код я продолжаю писать, но уже меньше и не в тех объемах. Отставать в развитии от современной разработки не хочется. В больших состоявшихся проектах, как мой текущий рабочий, взять и использовать всё самое современное не всегда получается, или это занимает много времени. Внедряем конечно и в таких ситуациях, но не так быстро, как хотелось бы. Самое «вкусное» внутри заметки, потому что не уложился в 1000 знаков :)

Первая статья — здесь.

Для начала — большое спасибо всем за то что приняли мою первую статью, было приятно. Ну а теперь вторая… :)

Frontend разработка штука конечно занятная и очень интересная, да и платят вкусно. Однако чем были хороши WP и MODx, так это готовой backend частью, на базе которой можно было на коленке собрать сайт почти любого типа. Мне очень не хотелось возвращаться к использованию CMS (про CMS будет в одной из следующих статей) и я решил внимательно изучить тренды backend индустрии для веб-приложений.

Перевод заметки Understanding addPackage, loadClass and getService
ВНИМАНИЕ! Актуально для MODx 2.*
Там на самом донышке пару строк про MODx 3 из официальной документации касательно данной темы

Повышайте свой уровень разработки на MODx. Присоединяйтесь к исследованию Боба (Bob Ray) о том, когда и зачем использовать каждый из трех методов загрузки классов MODX.