Дмитрий

Дмитрий

Был в сети 23 сентября 2022, 13:53
Заказы принимаю
Ребята правильно говорят, что этого не будет, потому что сделать это некому. Это долго, сложно, и дорого.
И, собственно, это реально одна из причин, почему у MODX какого-то развития за пределами её текущего положения не будет, как и притока новых разработчиков.
Хотите новых технологий — смотрите в сторону October CMS. Там уже и Vue.JS в админку завезли и много других классных плюшек на подходе. А главное — ребята из сообщества и команды ядра за пару лет сделали в десятки раз больше, чем в MODX было сделано за десять лет.

P.S. комрады, не сочтите за хейт или троллинг)
чтобы народ из MODX убегал на другую платформу, познакомившись с разработкой на фреймворках, а и обратное движение
А зачем, Сергей? Ценю и уважаю твой вклад, но кому и зачем в почти 2022 году нужен MODX? Система уже давно превратилась в легаси, безнадёжно устаревшее и бесперспективное. Привлекать кого-то молодого в MODX сейчас это даже просто как-то некрасиво и нечестно.
На php для меня MODX лучший
Чем он лучший? Тем, что не завезли ни неймспейсов, ни композера, ни вменяемого некостыльного механизма версионирования? Никому не нужный extJS в админке? MODX это конкретно так прошлый век PHP-разработки. Он, конечно, еще лет 10 будет встречаться в проектах, но будущего у него однозначно нет.
Да нет никакого готового кода и не может быть. Эти манипуляции легко провернуть на JS, как уже написали выше, но реализация полностью индивидуальна и зависит от того, как реализовано всё в твоем проекте. Даже если где-то есть код в свободном доступе с реализацией подобной задачи, тебе придётся переписать 90%, чтобы адаптировать под твой проект. В любом случае, придётся или разобраться с основами JS/jQuery, или заплатить программисту, который сделает это за час.
А какой технологии которая отвечает требованиям рынка в 2020 году не хватает в modx именно вам?
Современный JS вместо монструозного ExtJS. Возможность адекватной реализации REST/JSON API. Возможность лёгкого подключения популярных компонентов типа ORM, миграций, авторизаций и так далее. Безкостыльный контроль версий.
Если подходить к вопросу чисто формально, то да, троечка на своём месте.
А если подойти к нему с позиции коммерции и политики, возникает вопрос: помогут ли изменения, заложенные в MODX3, преодолеть стагнацию системы и вновь вывести её в авангард подобных технологий? Помогут ли они догнать стандарты, заложенные наиболее влиятельными игроками рынка? Делают ли они систему отвечающей всем требованиям рынка к подобным системам в 2020 году?
Столько разговоров было об «обратной совместимости», которая, тем не менее, оказалось довольно условной: рефакторинг дополнений в любом случае требуется, и некоторые компоненты теперь будут иметь две ветки, как, например, pdoTools. Да обратная совместимость вообще не была нужна! Старые сайты прекрасно бы работали на 2.x, а новые мы бы с удовольствием делали с новыми технологиями. Проблема, однако, в том, что никаких новых технологий кроме местами сомнительного редизайна админки MODX3 не принёс.
Пусть я буду диванным критиком — даже они нужны любому проекту. Как диванный критик я хочу задать вопрос: какие киллер-фичи MODX3 дали основание для смены мажорной версии? Что изменилось сравнимо с изменениями, появившимися после перехода с 1.x на 2.x?
Мне кажется, что некоторые члены сообщества пытаются сами себя убедить в том, что MODX3 — это какой-то прорыв. В то время как на самом деле это просто новый дизайн админки и куча фиксов. Это уместно было бы назвать MODX 2.8, быть может, но точно не MODX3. Переход от Evo к Revo был прорывом, а MODX3 это просто иллюстрация стагнации.
Всем кто не верит выход MODX 3.0 — могу только сказать, он выйдет, не смотря ни на что!

А есть где-то актуальный список изменений? Ради интереса поставил dev-ветку и кроме некоторых местами сомнительных изменений интерфейса разницы с 2.х.х не увидел) Пишу с позиции пользователя, может, под капотом есть какая-то особая незримая магия. ( ͡° ͜ʖ ͡°)
Человек, по всей видимости, пытался описать какие-то «best practices» по сборке сайта. Тема нужная, инициатива похвальная, но стоит лучше структурировать информацию, мне кажется, если взялся за это.
Пара моих наблюдений, прошу прощения, если было.
1. «Автоматизировать статические элементы» работает, но сбрасывает категорию после сохранения и повторного открытия элемента (по крайней мере, с чанками это так). То есть, если создать чанк head c категорией common, чанк сохранится по адресу /core/elements/chinks/common/head.chunk.tpl. Если же закрыть чанк и открыть его снова, категория пропадает из пути (/core/elements/chinks/head.chunk.tpl). Лечится выбором другой категории и затем повторным выбором нужной (при этом после выбора категории нужно снять фокус с селекта, только тогда категория включится в путь).
2. Почему-то перестал работать Ace в чанках. Выдаёт ошибки: