Сергей Шлоков

Кстати есть ли возможность проверить используется ли на странице где то стандартный парсер?

Он используется всегда.

Смешанный режим — это зло. Даже опытные разработчики путают последовательность при работе в этом режиме. Сначала работает феном, потом стандартный.

Вроде была статья. Но в ней как раз и писали, что феном не даёт прирост скорости. В документации есть тест по pdoTools. Вот он даёт. А феном — это лишняя нагрузка. Он не заменяет стандартный шаьлонизатор, а дополняет. Т.е. работают 2 шаблонизатора. Кроме того, кэшируемые теги MODX, написанные на феном, MODX переводит в свой формат (дополнительная нагрузка). Чтобы было понятно — кэшируемый тег MODX на странице превращается в результат и при следующем запросе страницы уже не вызывается (он распарсен). А феном тег остаётся и MODX должен дополнительно его обработать, перевести в MODX формат и проверить кэш.
Ну и плюс ещё разные неувязки. Я уже много раз о них писал.

Ну тут он будет полезен новичкам, или если нашёл где то решение в интернете или в документации, а там родной синтаксис, быстро его перевёл.

Хотел бы я посмотреть на такого новичка. Уверен, такого не найдётся.

Ещё раз повторю — феном имеет смысл использовать только ради его функциональных возможностей. Простая смена синтаксиса вызовов чанка или сниппета не только лишние затраты по времени, но и негативно сказывается на производительности сайта.

По-моему, просто достаточно примера как перевести теги чанка, сниппета и плейсхолдера из MODX формата в Fenom. Что-то типа cheat sheet. Ибо данный вариант сервиса способен переводить только простые конструкции.

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

А банальный перевод тега на Fenom (просто чтоб было) ничего не даёт. Даже хуже — MODX теги работают лучше и меньше нагружают парсер.

Ничего не могу сказать. Я первым делом тестирую на своем сайте. Обновилось без проблем.

Fenom, даже если и влияет на скорость сайта, то совсем не в положительную сторону. Вот сам pdoTools да. Там много чего оптимизировано по сравнению с кодом MODX.

Я склоняюсь к решению, которое я сделал в ZoomX — возможность указывать несколько путей для файловых элементов. В сторонних компонентах нужно будет использовать плагин на событие «pdoToolsOnFenomInit».

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

Это нереально и бессмысленно. Если только в качестве сервиса — ввёл тег MODX, получил варианты на Fenom. Потом вставил куда надо.

Собственно, наблюдая за тем как развивается MODx, у меня складывается впечатление что очень многое из того над чем сейчас работают люди, это либо мало кому будет нужно, либо уже совсем неактуально в свете последних тенденций рынка web-разработки.

Сергей попытался внести в MODx чуть-чуть современного подхода к бекенду, но большинству сайтоделов на MODx оно нахер не всралось. В чем я не прав-то? Я уже молчу про то, что на рынке эти инструменты которые создаются для MODx не востребованы, как и сам MODx.

Конечно не растут, потому что сам MODx в стагнации уже много лет и единственные кто его до сих пор держат на плаву, это единицы разработчиков платных дополнений и сам стерк, у которых бизнес на нем завязан.

Людям дали инструмент. Но любой человек который перешагнул по навыкам и знаниям MODx, уйдет в более современный и востребованный на рынке инструмент. Вон тут уже упомянули Laravel.

Тут лишь остается рассматреть вариант сборки сайтов на MODx в кач-ве фриланса. Вариант конечно имеет место быть, но крайне спорный… Лучше уж взять хороший фриланс заказ и создавать его на микросервисной архитектуре, используя современные инструменты.

Дискуссия. Много полезной пищи. Ещё больше её в комментариях про клиентов-лохов.

Вишенка на торте — «Баллада о железном слове» (мы в молодости называли это вагина-мяч) в двух актах.
Акт 1.

Да я могу целый список составить того, почему UI в MODx плохой и это будет не субъективная оценка, а отзывы которые я собирал годами от своих клиентов.

Акт 2.

Конечно я не буду тратить время на сбор списка причин, почему UI/UX админки в MODx плохой.

Занавес.

П.С. Всё сказанное про медленное развитие MODX верно. И про PR, висящие годами. Многие из нас уже мозоль на языке натерли говоря об этом. И я в первых рядах. Но на сайте сообщества MODX рассказывать про то, что сайты нужно собирать на микросервисной архитектуре, это уж как-то… Для таких новаторов нужно особые ресурсы создавать.

П.П.С. Всё вышесказанное Павлу прошу читать вежливо и с уважением, ибо мы знаем друг друга давно и просто спорим. )

Т.е. обещанного списка отзывов, собираемых годами от клиентов, не будет? Мда. Вот и всё, что нужно знать о холиварщиках. В лучшем случае (это в самом лучшем случае) получите список ишу Руслана Алеева про пермишены.

Да, и ещё, совет заказчикам — когда разработчик начинает нытьё о глюках дерева при большом количестве ресурсов, задумайтесь о его проф. пригодности.

Не воспринимайте как критику.

Почему? Критика бывает более полезна, чем восторженные отзывы.

Такие надстройки (так как их делают программисты для себя и других программистов) делают MODx более сложным.

Правильно ты пишешь про программистов. А для них как раз ничего сложного нет. Это дополнительный инструмент для работы, а не обязательная замена. Раньше, чтобы так кодить, нужно было уходить во фреймворки. Сейчас также можно работать и в MODX до какого-то момента. Разве это плохо?

Закреплю посыл — ZoomX не для массового использования. И, кстати, изначальная задумка была для замены MODX шаблонизатора. Идея навеянна Evolution CMS. Но ребята ядро переписали под Laravel. С MODX это невозможно. Поэтому и дополнение. А потом решение стало обрастать правилами фреймворков. Именно поэтому мажорные версии. Но при этом концепция CMS никуда не делась и новичкам ничего не нужно заново учить. Т.е. ZoomX позволяет как бы растянуть момент покидания MODX.

Уникальность MODx как раз в простой и удобной админке, в простом создании ресурсов, отображении их в виде понятного дерева с понятным редактированием этих ресурсов из админки. Доступ к шаблону из самого ресурса.

ZoomX ничего этого не меняет. Он меняет только правила шаблонизации. Один проход. Как это принято не только во фреймворках, но и в других CMS. Подход MODX с многократной обработкой регулярными выражениями себя (в наше время) не оправдывает. А PHP шаблонизаторы компилируют код, оптимизируют его за счёт Opcache. Это даёт и гибкость и скорость.

С приходом таких дополнений, как ZoomX, нужно прописывать роуты, а создание ресурса превращается в написание кода. Это вряд ли привлечёт большое количество новичков в MODx (именно эта категория пользователей даёт популярность таким проектам, как Wordpress).

Задача ZoomX не привлечь новичков, а удержать старых разработчиков. А если бы ты попробовал его или хотя бы прочитал доку, то не писал бы такое. )

Да я могу целый список составить того, почему UI в MODx плохой

Составь. Уверен, все только спасибо скажут.

Как сказал Николай, в MODX3 мажорные изменения. Теперь работа организована через композер и все классы имеют неймспейс. А дополнения для MODX2 работают с классами без неймспейса. Поэтому они нормально работать в тройке не будут.

Бывает на апаче на сайте с отсутствующей favicon.ico.

Ну докрутить ещё маршрутизацию (middleware, имена роутов) + нормальный контейнер зависимостей и будет очень близко (если не сравнивать xPDO и Eloquent). Ну ещё аутентификацию для API.

Я тоже этого жду ;)

Спасибо, что тестируете!

Спасибо за помощь в тестировании!
Дело в том, что tplOuter также является и шаблоном для tplInner, если последний не указан. А по умолчанию он пустой. Поэтому так и получается.

Вот тут можно подробнее почитать про параметры сниппета pdoMenu.

Это сделать абсолютно не сложно. Добавлю в следующей версии. Просто интересно, зачем дебажить сразу 2 вызова одного и того же сниппета?