Александр

Александр

Был в сети 30 июня 2026, 15:55
Заказы принимаю
Именно, вам не повезло или вы так специалистов выбирали. Например, не могу порекомендовать себя на данный момент в этом стеке, т.к. сам учусь в процессе.

Сколько людей, столько и мнений, возможно, вам этот подход не подходит, а может не разобрались толком, а может используете не там, где надо, а может «спецы» такие и т.д. Есть масса задач, для которых CMS подходят куда лучше, ибо нечего велосипед изобретать, а есть такие, реализуя которые на CMS сталкиваешься с массой сложностей и ограничений. Василий отлично описал это в статье, упомянутой выше в комментарии. В мире MODx — это ExtJS, это конфликтующий сам с собой Composer (а точнее разные версии дополнений, необходимые для разные дополнений) и т.д. Сравните реализацию одного и того же на Vue и ExtJS.

Такая компания, как Сбер, наприимер, использую не по наслышке React, не жалуется ?

Ух, где же Вы, Николай Ланец, вас в этом обсуждении очень не хватает :)
Доброго времени суток ✌

Думаю, как и многие здесь, начал разработку сайтов благодаря курсам, заметкам и пакетам, созданными
@Василий Наумкин. Лично я стал зарабатывать первые деньги именно благодаря MODx и Василию. Дай Бог Вам здоровья! ?

Сейчас же, Василий создал несколько курсов (в данный момент в бесплатном доступе на bezumkin.ru) по своей новой системе VESP: Vue + Eloquent + Slim + Phinx. Статьи, где упомнут такой выбор стека, к сожалению, не нашёл, помню, что выбор пал из-за того, что PHP хорошо знаком (мягко говоря) и переход на более современные тенденции более плавный. Мне эта идея понравилась и, изучая курсы, стал сразу работать над новым проектом, используя новую систему. Легче задышалось! Вы сами выбираете, где и что как должно работать, система вас не ограничивает! Рекомендация к прочтению: bezumkin.ru/sections/projects/3075
Понимаю, что создание того же (а именно агрегатор для бань с календарем и массой нестандартных решений) на MODx, несмотря на имеющийся Agenda, котрый покрывал 80% моих задач, был бы сплошной мукой. Даже простые вещи, как например, доабвить в календарь вывод номера телефона, ведь пришлось бы править исходники или выдумыать, как инетгрироваться в пакет без правок.

API на PHP, причём некотрые вещи, типо миграций и управление базой данных идентичны Laravel, а он в свою очередь имеет огромное сообщество, дополнения, инструкции и т.д. А управление фронтендом перенеслось на Vue + Nuxt для серверного рендера.
Выбор стека может быть любым: будь то полный переход на JS, как вы описали, или же React + дополения для роутинга и т.д. Vue — фреймворк, React — библиотека, и разница в том, что во Vue и Nuxt за вас уже решили (стандартизировали, можно сказать) структуру и архитектуру, не нужно придумывать велосипед. В React же выбор остается за программистом и стек может быть очень разным, как структура проекта, так и используемые технологии. Думаю, многие оценили прелести линтеров и преттиеров для js. Бесят, но зато разбираться в своем/чужом коде, оформленным по определенным правилам, куда проще ?

Выбор за вами :) Если полный переход на JS вас не пугает, как совершенно новое, чему придётся учиться с нуля — вперёд, всё получится! ?
Работу обоих компонентов вы можете проверить на modhost.pro бесплатно в течение 24 часов.
физически нельзя будет пройти на страницу msk.site.ru/catalog/page-one
можно

cityFields больше про изменение цены товара от различного региона, но также можно

Оба компонента под ваши нужды должны подойти. Если регионов не так много, можно сделать через лексиконы. Например, в плейсхолдере [[*region]] хранится код текущего региона (msk, spb), а в лексиконе [[%region_name_[[*region]]]] ([[%region_name_msk]], [[%region_name_spb]]) название конкретного региона и т.д.
Аа, это… Будет классно, если у каждого изображения в контекстном меню появится кнопка «заменить превью». Появляется окно с превьюшками этого изображения, каждое из которых можно вручную заменить. Бывает, phpThumb подрежет изображение не совсем так, как будет лучше для конкретного изображения, а так выборочно неудачные кадры можно будет заменять.
В потенциале добавить ещё встроенный мини-редактор, в котором можно вручную кропнуть, немного настройки подкрутить (насыщенность, яркость и т.д.). Вот это будет сильно! :)
Каждый раз вызывать программиста, верстальщика, разработчика для того, чтобы изменить какую-нибудь мелочь — тоже дело довольно странное. Речь ведь не о функциональных возможностях, не о программировании, а о контенте, о том, как ог отображается. И, если надо убрать несколько строк CSS из тех файлов, что есть, то это вызывает слишком много лишних телодвижений, занимающих время, которое продуктивнее направить в другое русло.

Ваш метод хорош, а желание совместить приятное с полезным, чтобы всем было удобно, остаётся.
Самый логичный способ — добавить 1 кнопку для ребилда скриптов, стилей и т.д. Идеально же!
Это, конечно, здорово, но вопрос никак не отменяет :)
Пример. Создал я в удобном для меня окружении сайт, всё без админки, по фен-шую! Но, пришёл после меня менеджер, которую эти webpack / gulp совсем ни о чём не говорят, ему надо только шрифт в нескольких местах изменить, да скриптов пару поправить. И для этого ему надо подключаться по ssh, чтобы в терминалы выполнить npm run build? Это неудобно)
Чистая установка MODX (проверил на modhost), установлен только pdoTools. Включена опция pdotools_fenom_parser. Добавляем новую запись словаря в core:default. Стандартный MODX синтаксис корректно выводит нужную запись всякий раз, а вот через Fenom всё работает только 1 раз (сразу после очистки кэша), а со второй загрузки страницы показывает вместо значения название самой записи.
Странно работает валидация как-то. В методе validate() сначала вызывается событие msOnBeforeValidateOrderValue, потом идёт встроенная в метод валидация полученного из события значения, далее вызывается событие msOnValidateOrderValue с новым (после валидации) значением, старое значение, до встроенной в метод валидации в это событие не передаётся, т.е. значение поля телефон, например, всегда будет обрезаться до 15 символов.