Субъективно более чем

Если бы. Мой первый клиент которому я делал магазин года 3 назад сказал, а как я буду пользоваться админкой с планшета? А что будет с древовидным меню если у тебя на сайте будет много-много ресурсов? А «тихое переименовывание» одноименных файлов? Да я могу целый список составить того, почему UI в MODx плохой и это будет не субъективная оценка, а отзывы которые я собирал годами от своих клиентов.

Вот тут ты хорошую тему затронул. Я для этого использовал контексты, типа есть dev и прод и всем весело было. Надеюсь.

Очень удобно, когда у тебя сайт на 2-3-4 языках которые сделаны на контекстах. Это костыли, а не полноценная разработка на локальной машине с последующим тестированием на каком-нибудь сервере.

Сиди создавай за миллионы корпоративные сайты.

Как хорошо что именно этим я и не занимаюсь собственно.

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

Субъективно более чем

Но представить что эти же клиенты получают на выходе проект, который не запускается в dev и stagging режимах.

Вот тут ты хорошую тему затронул. Я для этого использовал контексты, типа есть dev и прод и всем весело было. Надеюсь.

Мои клиенты нынче это тир1 финтех компании чей капитал больше бюджета твоего города. Лохи? Может быть, я так не считаю.

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

то есть по твоей логике в современных ресурсах...

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

Но представить что эти же клиенты получают на выходе проект, который не запускается в dev и stagging режимах. Над которым невероятно сложно работать в команде и который крайне сложно передать другим разработчикам на хотя бы лет 5 стабильной работы/доработки без рефакторинга. И уж тем более не версионируется… Нуу… Не, не могу представить. Хотя нет, вру, могу — если клиенты лохи.

Проблема тройки — овощи у которых на гитхабе права на репозиторий, при чем тут вообще сторонние инструменты?

Не буду разворачивать про тройку дискус, время покажет насколько эта штука нужна миру.

P.S.
И все таки я не понимаю в чем был не прав… В том что ZoomX будут пользоваться единицы или в том, что это шаблонизатор или про выбор MODx как инструмента для создания сайтов?

$router->get('uri', function() {
Очень похожи на

app.get('/', function(req, res) {
В каком-нибудь Express.

А, ну роутинг урлов очень похож на роутинг апи. Зафиксировали.

То ты очень классно обул клиентов-лохов.

Мои клиенты нынче это тир1 финтех компании чей капитал больше бюджета твоего города. Лохи? Может быть, я так не считаю.

Самое сложное в сайтецах для корпоративов — это верстка.

Кто ж спорит с этим? Как это влияет вообще на бэк сайта?

Нафига им вообще бек? Статику выплевываешь с небольшой логикой обработки каких-нибудь форм.

То есть по твоей логике в современных ресурсах нет никаких работ над сайтом? Ну то есть вообще никаких?

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

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

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

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

Проблема тройки — овощи у которых на гитхабе права на репозиторий, при чем тут вообще сторонние инструменты?

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

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

$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 не сортирует, если убрать эту сортировку то все ресурсы выводятся, как исправить?