По мотивам комментариев...
В мире PHP шаблонизаторов нет понятия файловых элементов. Это наследство MODX. Его разработчики под давлением общественности в свое время ввели понятие статических элементов. А мы в RU сообществе придумали другой костыль на основе Fenom. Но и то и другое - костыли. В PHP шаблонизаторах место сниппетов занимают сервисы. Сниппет - это говоря откровенно, архаизм. В своё время это было интересным решением, но сейчас разработка пошла по другому пути развития. Появились паттерны, общие стандарты. Нельзя застаиваться в прошлом.

Мы же все понимаем, что ExtJs 3.4 - это что-то из предыдущей жизни. Так вот и чанки со сниппетами - это тоже самое. В современном мире разработки чанки - это подшаблоны, а сниппеты - это сервисы. Развиваясь в этой парадигме вы расширяете себе поле собственной полезности. Людям, окунувшимся в мир современной разработки, уже не хочется загонять себя в узкие рамки правил MODX. Ланец, Наумкин, But1head, Киреев, Воеводский, Кузнецов, Лукьяненко и многие другие из списка разработчиков modx.pro.

ZoomX - это попытка дать таким людям возможность остаться и использовать современные методы разработки. Мы много говорили о MODX3. Многие ещё не оставили надежду. Я уже давно не верю, что он когда-нибудь выйдет. Поэтому делаю свой вклад в его развитие по своему.

Кто-нибудь хоть раз пользовался функционалом прав доступа из компонента AdminTools?

В рамках создания набора инструментов для ZoomX интересен такой вопрос - кто-нибудь использует меню с динамическим наполнением? Т.е. чтобы в меню (главном, боковом и т.д.) появлялись элементы, которые добавляются в процессе жизни сайта. Или один раз настроили и всё?

Оказалось, что никакой надобности писать отдельную библиотеку взамен pdoTools нет. В modHelpers есть практически весь необходимый функционал.

Кроме альтернативной шаблонизации ZoomX добавляет полноценную поддержку RESTful API. И вы сами можете выбирать, что использовать - только шаблонизацию, только RESTful API или и то и другое.

Информация для информирования.

Если пользователь обращается к странице, на доступ к которой у него нет прав, MODX выдаст ошибку 401 Unauthorized. Но мы с вами продвинутые разработчики и знаем, что код HTTP 401 требует аутентификации пользователя. Т.е. говоря по-русски, нужно залогиниться. А вот, чтобы указать на отсутствие прав доступа, предусмотрен код 403. В ZoomX этот момент исправлен.

https://ru.wikipedia.org/wiki/%D0%A1%D0%BF%D0%B8%D1%81%D0%BE%D0%BA_%D0%BA%D0%BE%D0%B4%D0%BE%D0%B2_%D1%81%D0%BE%D1%81%D1%82%D0%BE%D1%8F%D0%BD%D0%B8%D1%8F_HTTP#401

Middlewares 1.1.1-pl.

В новой версии исправлена ошибка, возникающая при обновлении сайта.

ZoomX 2.1. Настоящие виртуальный страницы

https://modzone.ru/blog/2021/02/26/zoomx-2.1-disable-resource-autoloading/

ZoomX 2.1.1. Исправлены некоторые баги, в том числе в RESTful API механизме.

Логирование пользовательских сообщений в отдельном журнале

https://modzone.ru/blog/2021/03/05/custom-logging/

Возможные проблемы безопасности сниппета pdoUsers мы уже обсуждали. Сейчас я хочу рассказать о возможных проблемах универсальности модификатора user (userinfo) шаблонизатора Fenom из pdoTools.

Как многие уже знают по модификатору resource, модификатор user также может работать и с именем поля и с id. Слава Богу, этот модификатор в отличие от сниппета удаляет важные данные (пароль, соль, id сессии), но некоторые данные он всё равно оставляет (remote_key, remote_data, hash_class). И они в некоторых случаях могут быть использованы злыми контент-менеджерами - {1 | user : 'remote_key'}.

Вот чтобы избежать этого в ZoomX есть 2 отдельных модификатора - user и userinfo. Первый выдает немного обрезанную информацию для текущего пользователя сайта. А второй ищет пользователя по id и максимально урезает выдаваемые данные, чтобы контент-менеджер не смог получить данные любого пользователя. Наш девиз -"Лучше перебдеть, чем не добдеть!". 😄

Я не выдержал и всё-таки чуть исправил процесс сборки пакета в браузере. Надоело видеть пустую страницу несколько секунд без какой-либо обратной связи. Теперь загружается HTML страничка и выводится наглядная информация о процессе сборки. Хочу для себя форкнуть modExtra, добавить туда эту фичу и убрать все ненужные зависимости типа Office.

Ещё очень удивлён, что никто до сих пор не сделал запуск скрипта в index.php файле, чтобы не писать modExtra/_build/build.php.

Небольшая дискуссия на тему Smarty vs Fenom. Правда оппонент приводит данные для классического использования Fenom и не учитывает его реализацию для MODX.

https://modzone.ru/blog/2021/01/20/comparison-of-template-engines/#comment-673

В последние дни я много времени уделяю MODX и особенно 3-ей версии. А ещё меня включили в список интеграторов на GitHub. В связи с этими фактами я в ближайшее время выпущу адаптированные к третьей версии MODX свои дополнения controlErrorLog и modalConsole. Они очень выручают при разработке и тестировании. Дополнение tagElementPlugin по идее должно работать на тройке. А вот другие мои дополнения требуют глобальной переработки. Поэтому их я оставлю на следующую итерацию выпуска MODX3.

Вышла новая мажорная версия библиотеки modHelpers. Основные изменения
- Добавлена новая функция "build_tree", формирующая древовидную структуру данных.
- Добавлена новая функция "reading_time" для подсчёта времени чтения текста.
- Добавлена новая функция "sanitize_path", исключающая возможность манипулирования путями.
- Добавлена новая функция "value". Аналог одноимённому хелперу из Laravel, но позволяет указать дефолтное значение для null.
- Удалена функция "faker" и соответствующее дополнение Faker. Используется крайне редко и только при разработке. В продакшене не нужен. Даже урезанный занимает больше половины объема пакета. Кроме того, автор перестал её поддерживать.
- Функция "dump" теперь может принимать несколько аргументов.
- В функции "login" и "logout" добавлен параметр "ctx", позволяющий указать контекст.
- Исправлен баг с добавлением вложений в классе Mailer (#2).

Как и обещал, выпустил controlErrorLog, адаптированный для MODX3. Может пригодится.

Статья, раскрывающая подробности новой версии modHelpers.

https://modzone.ru/blog/2021/05/03/modhelpers-v4-0-0/

Частенько, ковыряя код ядра MODX, встречаешь такие вещи, которые просто просятся в рубрику "Так лучше не делать". Несколько лет назад я даже записывал их. Правда теперь найти не могу.

Хотел спросить - было бы интересно выкладывать такие вещи здесь с моим альтернативным решением? Предвосхищая обвинения в подрыве репутации MODX сразу скажу, что тут речь больше про прокачку PHP навыков, а MODX просто как источник примеров.

Рубрика "Так лучше не делать"

Итак, первое, с чего бы хотелось начать, использование ссылок в аргументах методов. Это встречается практически во всех классах MODX, которые не являются объектами базы данных. А ещё при вызове событий, если в них передаются объекты. А также во многих компонентах MODX.

Это наследие PHP4. В PHP5 работу с объектами переосмыслили. Теперь они хранятся в хэш таблицах. А переменная объекта хранит всего лишь ссылку на объект в этой хэш таблице, а не сам объект. Поэтому начиная с PHP5 нет необходимости принудительно передавать ссылку. Но даже в MODX3, требующей PHP7.1, данный легаси остался нетронутым.

Обратите внимание на картинку. Плагин PHP Inspections (PhpStorm) так об этом и говорит.

П.С. Про ссылки можно более подробно прочитать у меня на сайте https://modzone.ru/blog/?tag=PHP

Помню, в сообществе периодически возникала дискуссия на тему - почему компонент, который создаёт в базе данных свои таблицы, не чистит базу от этих таблиц при своём удалении?
За последние пару лет я не встречал подобных вопросов. А кто-нибудь знает, как правильно удалять таблицы при деинсталяции компонента?

Класс modX