Когда ты последний раз писал апи? Обычный роутинг обычного проекта, при чем тут апи вообще?

Каждый день занимаюсь этим на протяжении последних полутора лет. И вот такие вещи

$router->get('uri', function() {

Очень похожи на

app.get('/', function(req, res) {

В каком-нибудь Express.

Если у меня средне-высоко бюджетный проект где нужно накидать сайтец для корпоратов я пойду брать фреймворк? Да?

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

Проблема MODX в том, что разработчики в нем не растут...

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

Ты сам знаешь думаю, в IT стоит перестать интересоваться новым на пару лет, как ты уже начинаешь выплывать из сферы.

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

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

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

Сергей написал просто более менее актуальный шаблонизатор

что? каво?

То что я вижу в примерах выше, очень похоже на то, как пишется сегодня какой-нибудь REST API

Когда ты последний раз писал апи? Обычный роутинг обычного проекта, при чем тут апи вообще?

Так что, ZoomX это заранее мертворожденный продукт, которым кмк будут пользоваться единицы. Все задачи для создания низкобюджетных сайтов на MODx — покрывает pdoTools с феномом.

Но в MODx это почти нахер никому не нужно.

а, ну расскажешь

Если у тебя будет средне или высоко бюджетный проект на котором потребуется хороший бек, ты уж точно не выберешь MODx с ZoomX или Fenom и пойдешь писать свой бек на каком-либо фреймворке.

Если у меня средне-высоко бюджетный проект где нужно накидать сайтец для корпоратов я пойду брать фреймворк? Да?

Так что, ZoomX это заранее мертворожденный продукт, которым кмк будут пользоваться единицы. Все задачи для создания низкобюджетных сайтов на MODx — покрывает pdoTools с феномом.

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

Объясни конечно, почему я должен гадать?

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

С этим согласен, более чем. А с постом твоим большим нет. Нужно пояснить почему или догадаешься сам?

Ты если не согласен с чем-то, напиши с чем, возможно я не прав и ты меня переубедишь, если не хочешь писать, то нахера высрался? )

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

вас обоих контузия взяла или это прикол какой-то?

Интересные проекты… У меня ни один проект не обходился без какого-нибудь pdoMenu или pdoResources. Я не про написание самих сниппетов с нуля, а составление уже готовых сниппетов.

Согласен со всем, кроме этого:

… MODx не простой, т.к. для того чтобы собрать сайтец нужно как минимум уметь писать сниппеты, хотя бы самые простые на modParser.

Есть несколько «сложных проектов» (структурно и функционально) собранных без написания сниппетов и без знания программирования. Использовали только готовые компоненты из modstore.
В остальном — полностью согласен.

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

То что я вижу в примерах выше, очень похоже на то, как пишется сегодня какой-нибудь REST API. Но в MODx это почти нахер никому не нужно. Если у тебя будет средне или высоко бюджетный проект на котором потребуется хороший бек, ты уж точно не выберешь MODx с ZoomX или Fenom и пойдешь писать свой бек на каком-либо фреймворке.

Так что, ZoomX это заранее мертворожденный продукт, которым кмк будут пользоваться единицы. Все задачи для создания низкобюджетных сайтов на MODx — покрывает pdoTools с феномом.

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

modx.pro/components/22537#comment-131710

Инструмент потрясающий. Ощущение, что пишешь на Laravel. Теперь вся жизнь в файлах и коде. Я уж забывать начинаю как админка выглядит.

Не воспринимайте как критику. Просто мысли вслух. Автору дополнения — искреннее уважение.

ZoomX — штука, безусловно, интересная :)
Но, на мой взгляд, уводит MODx от концепции более-менее простой и универсальной CMF к сложному «недофреймворку». Вместо того, чтобы менять сам MODx и делать его более быстрым, удобным и понятным большинству, я вижу тенденцию к уходу в доработку надстройками. Такие надстройки (так как их делают программисты для себя и других программистов) делают MODx более сложным.
Уникальность MODx как раз в простой и удобной админке, в простом создании ресурсов, отображении их в виде понятного дерева с понятным редактированием этих ресурсов из админки. Доступ к шаблону из самого ресурса. Система сама заботится о создании ссылок, их формировании и т.д. Простые дополнения, позволяют вывести меню, ресурсы, добавить форму, создать простой магазин и проч. Все это просто понять и применять новичкам.

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

В любом случае — автор молодец, что посвящает этому время.

Надо showLog сделать, но я бы кавычки убрал, вот так

{"publishedon:>=": [[!timestampToUnixTime? &dt=`[[!#GET.news-year]]` &next=`0`]], "AND:publishedon:<=": [[!timestampToUnixTime? &dt=`[[!#GET.news-year]]` &next=`1`]]}

Возможно что-то не так с чанком в сниппите msGetOrder. Пробовали стандартный использовать?

Думаю в msGallery эти поля должны быть, ведь внутри чанка pl.msProducts.row вы вызываете сниппет msGallery?

Согласно описанию сниппета ms2GalleryResources:

Сниппет для вывода ресурсов через pdoResources с присоединением первой картинки из галереи ресурса.

Отсюда следует, что твоё TV надо тоже присоединить, это делается параметром includeTVs.

Для новых документов такое решение может и пойдет, но для ресурсов которые уже созданы, это дублирование. Ведь можно добавить флажок в системных настройках «использовать язык по умолчанию для стандартных полей ресурса». Либо расширить плагин или сниппет, который может на прямую запросы строить без обязательной привязке к класу «localizatorContent» (к примеру если вызывать pdoPage c ajax button, то пагинация не работает, говорит что не знает про класс localizatorContent при нажатии на кнопку «Подгрузить еще», а это из-за расширения стандартного pdoFetch — если вызывать сниппет pdoPage без leftjoin, select, where). Просто хочеться чуть больше гибкости, чтобы сайт который уже работает с 1000 новостями не перебивать через скрипты тупо дублируя их еще в одной таблице для стандартного языка (ru) и для английского языка (en). Ведь никто не будет переводить старые новости, а просто оставит старые как есть, причем на двух языках, но не выводить их не правильно, и дублировать не правильно.

Снипет рабочий выдаёт год из гета и след год в Unix, но всё равно pdo не сортирует, если убрать эту сортировку то все ресурсы выводятся, как исправить?

Понятно, спасибо

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

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

@evo_ave