Объект $modx легко получается и при выключенной настройке. Так, для информации.

Важно только, что при таком раскладе нужен доступ к объекту $modx, с pdoTools и выключенным доступом к объекту (так по умолчанию) такая фишка не прокатит. А упрощенный класс $_modx не даст нужного результата, его нужно допилить, чтобы он возвращал все поля контекста.

Проверил, да так реально, работает, Сергей как всегда, спасибо!

Если ресурс уже подгружен, то можно получить контекст через него

$modx->resource->Context

Спасибо

Отправил Issue — github.com/modxcms/revolution/issues/15653

А что с ней не так?

Тоже хотел вам предложить через BETWEEN, но не был уверен, что сработает.

github.com/modxcms/revolution/issues/new?assignees=&labels=bug&template=bug_report.md

Ещё бы разработчики знали об этом. Не стесняйтесь создавать issue.

Доброго дня.
Уже доступно в магазине.

Быстрее и дешевле — да. Если речь о быстром старте и потом забыть об этом. Но если в дальнейшем это поддерживать и развивать, то очень и очень спорно.

Тем не менее, мне действительно нечего сейчас такого показать, чтобы «вжух и готово». В любом случае приходится программировать, а не просто интегрировать. Тем не менее, если что такое появится (а оно должно появиться), я покажу.

Спасибо за развернутый ответ! А за vercel отдельное спасибо))) я натыкался на него ранее, но почемуто посчитал, что это хостинг чисто для статики.

сейчас спроса на простые и маленькие практически нет

Тут не соглашусь, у меня часто в работе лендинги для бизнеса у которых цель заключается в том, чтобы прорекламировать продукт и затем чтобы клиент зарегистрировался/подписался на рассылку или чтонибудь такое. Из требований там только чтобы текст и картинки менялись менеджерами, вот для таких случаев разрабатывать API-first на томже strapi + nuxtjs (или чем либо другом) банально дольше чем накатить верстку на modx подключить форму к formit и выкатить в прод.

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

Както натыкался на статью, когда компания решила отказаться от вебпака в пользу своего решения и рассказывали, что у них сборка проекта производилась на 20% быстрее, а затем через годы программисты которые работали над этим решением уволились, документации никакой небыло и нужно было добавить в это решение поддержку postcss, в итоге проект начал собираться адски долго и все снова вернулись на вебпак)))

Иван, профиль глянь. Это же спам.

• modx.pro/news/21547
• modx.pro/news/21451
• vk.com/wall-61152387_1906
• 2 закрепленных сообщения в t.me/ru_modx

А что с первой версией?

А я даже нигде не слышала об этом

Аа, забыл сказать. Этот самый vercel выкупили фреймворк next-js и совместно запилили Next.js Commerce. Так что теперь и интернет-магазинчики можно клепать на этих технологиях.

Есть решения на nodejs, но тут сталкиваемся с тем, что тогда нужен сервер, либо нужно мириться с своеобразными решениями хостингов.

Нет, это сильно не так. Сейчас появляются специализированные хостинги, например https://vercel.com. Заходишь в панель, указываешь ссылку на гитхаб-проект, даешь к нему доступ и все. Далее при каждом коммите в мастер-ветку он сам стягивает исходники с гитхаба, собирает все и разворачивает на сервере. Ты вообще ничего не делаешь.

Я им не пользуюсь, но морок все равно не много. Я захожу на digitalocean и создаю сервер из готового образа с докером: marketplace.digitalocean.com/apps/docker
Далее просто затягиваю гит-проект, подправляю .env (если надо) и все, запускаю проект. При чем использую caddy-server, который даже ssl сертификаты в Let's Encript заказывает, даже крон-службы никакие не надо настраивать. Так что все далеко не так плохи и сложно как кажется.

В связи с чем появляется вопрос, а чем можно заменить modx в современных реалиях?

Вот если говорить просто как про замену MODX в классическом виде, то есть про готовую CMS, которая и сервер и фронт, все в одном, под сайты-визитки и небольшие магазины, то скорее всего нечем (во всяком случае на JS/TS). Нюанс только заключается в том, что сейчас спроса на простые и маленькие практически нет. Точнее сейчас практически не остается того маленького в том виде, как это было раньше. Даже маленькое сейчас стараются делать по современным методикам. Аналогию можно наверно такую провести: это как писали раньше на чистом JS и мучились с поддержкой разных браузеров, а потом появился jQuery и практически все стали писать на нем (хотя справедливости ради стоит отметить, что сначала появились prototype и mootools, но все же именно jQuery стал первой столь массовой библиотекой). Или как писали чистый CSS, а потом появились Less, Sass и т.п. и говорили «На чистом CSS писать легко. Но большие проекты на чистом CSS писать сложно». Так же и здесь. Появляется множество инструментов, используемых еще на этапе разработки и конечный продукт без использования оных всерьез не воспринимается.

Сейчас же пишут в основном API-first CMS и Headless CMS. И хотя не все могут сразу перейти полностью на новые технологии, очень часто делают так: бэк старый оставляют и прикручивают новый на новых технологиях. Посмотрите список поддерживаемых CMS у того же gatsby или next-js. Я же пишу свой велосипед, который прям все в одном в плане и бэк и фронт. github.com/prisma-cms/nextjs
Сделал на нем уже несколько сайтов. Докручиваю только более удобную админку ему. Уверен, появятся и другие сторонние решения «под ключ» и более удобные, чем у меня. Это всего лишь вопрос времени.

Подскажите, пожалуйста, а как cast используется в where?

Я решил проблему но другим способом:

$where = array(
	"0" => "Lo BETWEEN 99 AND 140",
);

$output = $modx->runSnippet('pdoResources',array(
    'limit' => 15,
    'parents' => 71,
    'includeTVs' => 'Lo',
    'where' => $where,
    'return' => 'json'
));

return $output;