9 минут назад
Я и не искал. С новым Formit необходимость в Fetchit и аналогах отпала. Переезд легкий, только событие в js изменить.
FormIt 5.2: нативный AJAX и reCAPTCHA v3 7
Сегодня в 01:24
Класс! Часто непонятно как искать причины поломок или откуда берутся сообщения. Это прям мучение. Посмотрим как работает новый компонент. Делаю у себя...
Хватит логгировать как в каменном веке 🪵 4
Сегодня в 01:17
Кстати вопрос возник. Раздражало что для базовой локализации надо было делать версию ru — т.е. создавать дублирование информации из полей и доп.полей....
Localizator3 для MODX 3: перевод полей и TV без отдельного context на язык, Vue 3 + PrimeVue 2
22 июня 2026, 23:07
Стоит подумать и добавить, так как 100% потребуется как-то модифицировать данные из 1С. Частый кейс это не соответствие категорий на сайте и категорий...
CommerceBridge 1C — двусторонняя интеграция 1С с MODX 3 и miniShop3 по CommerceML 2. 7
20 июня 2026, 17:54
Только что столкнулся с таким на modx3, ранее 1 раз видел на modx 2.8 — не было времени и мотивации разбираться.
Но проблема есть и она старая.
Кл...
Не срабатывают статичные плагины 1
19 июня 2026, 23:14
Обновление компонента
История изменений MaxNotify 3
1.2.0-pl
добавлен канал max в Центр уведомлений miniShop3;добавлена отправка из Центра дл...
MaxNotify3 3
19 июня 2026, 21:05
Копать надо в браузере. На вкладке сеть, если ответ 500, тогда в логи сервера.
Зависает корзина минишоп2 1
Всего 125 989 комментариев
Для data-show-partner используешь, к примеру, id ресурса через [[+id]], либо [[+idx]]
А потом для каждой страны делаешь свой вызов pdoResources, чтобы вывести дочерние элементы.
Хотя, может получится опять же все завернуть в один вызов pdoMenu (смотря, насколько там сложная верстка).
Значит основная проблема — бекенд. У вас API для 200 таблиц написан на MODx, где у вас все таки связаны руки. Значит перенести эту логику в условную лару не составит труда. Это же просто работа с данными которые лежат где-то в БД.
Зачем ночами сидеть и пытаться запихать на фронт сайта, который сделан на MODx — Vue, я хз. Еще вам придется решать вопросы зависимости компонентов от jQuery.
Ну… Это так, мысли в слух. Я не удивлен если у тебя на сайте будет и Vue и jQuery и что-то на ванильке. Франкеншейты они такие…
При использовании компонента постоянно выскакивает ошибка
/var/www/u2436897/data/www/..............ru/core/cache/includes/elements/modx/revolution/modplugin/11.include.cache.php 14 PHP warning: Undefined array key «SendIt»
Чисто на товары Vue и не надо. Надо на динамичное приложение. Уже надоело как надо показать какую-то не стандартную модалку, то чанки на феном и он на фронте не работает. Приходиться идти по ajax на сервер выбирать отдельно данные закидывать их в чанк и html уже забирать. Много лишних телодвижений. Шаблоны лучше на фронте заливать данными. По большому счету я хорошо знаком только с модекс. Другие системы смотрел, но что-то не производят они впечатления. Пару api можно быстро создать, но чтоб чисто сделать апи для 200 таблиц понадобиться год. И еще год фронт написать. Тут на работе не будут ждать 2 года, чтоб у них все заработало. Новое можно только постепенно. Сейчас неделю ночи трачу обдумывая как на основе модекс бек сделать. По идее в часов 200 в течении 2-3 месяцев можно сделать такой функционал, что потом переезд будет в разы проше чем на каком-либо другом беке.
Пару лет назад я думал — было бы отлично, если бы MODx и его компоненты могли поставлять хороший и удобный REST. Там и админку свою можно набросать и на фронте наконец-то уйти от фенома и сниппетов. Сейчас я понимаю что был ох как не прав, куда проще сесть и начать писать свой бекенд. Вопрос лишь в финансах и желании. Если хотя бы один фактор отсутствует, то хер знает зачем тратить кучу времени и изобретать франкенштейна… Берешь MODx и пользуешь как есть. Товары будут продаваться и без Vue.js.
Нужно повнимательнее перепроверить, но это в свободное время.