Наумов Алексей

Наумов Алексей

Был в сети 28 июля 2026, 14:21
Заказы принимаю
Если url действительно сайт.ру/категория/товар, то вы можете написать правило:
/{category}/{product}/reviews
событие onHandleRequest, обработчик — например Ресурс. А на странице ресурса вызвать уже сниппет некий. Задача этого сниппета — найти product, и вызвать ecForm и ecMessages, передав им соответствующий thread.
Добрый день.

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

Уберите в настройках компонента пути к файлам стилей и скриптов и подключите их вручную в шаблон сайта.
Тоже сталкивался с парой сайтов у них.

Начать можно с того, что там что-то типа облака, и бац, нет FTP (ну про ssh и заикаться не буду)!

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

В общем буэ. Зато когда продажу разработки сайта делаешь — «фу, какие 50 тыщ, вон за 10 интернет магазин предлагают», а потом правда, как поставить событие в метрике никто не знает)
«на фронте их нельзя выводить»
Я делал так: страница опубликована, но у нее снят флаг «searchable». Считаю это признаком неопубликованного товара. Проблему отображения страницы решал через плагин, проверяя поле и отдавая 404 ошибку. Ну и не забыть из всяких выборок убрать такие страницы, используя любое условие (по шаблону или searchable, как удобнее).
Сложно сказать, что там проще, я не использовал никогда ms2form.

Если в id дело, то надо у форм прописывать че нить типа id=«form-[[+id]]». Если не жестко все это прописано по 10 раз в коде — то, думаю, все исправимо.

Если сложно исправить переделать, что бы каждый tab был отдельной страницей, проблема уйдет.
Да, если множественный выбор, то только отдельная таблица. Хотя можно и дублирование данных, в таблице с товарами данные в JSON, например, + отдельная таблица. В разных ситуациях разные способы получения данных, тут главное скорость работы, а не несколько Мб данных лишних.

По АПИ — да, все так поняли, не взирая на кажущуюся сложность это абсолютно рабочий способ. Издержки на лишний запрос к сервису, как правило, не очень большие. В общем подумать стоит
Поговаривают, что JOIN — не очень быстрая операция.

Если параметры для товаров едины — зачем их выносить в отдельную таблицу то?

Можно подумать вообще с точки зрения архитектуры поступить так: отдельно сайт на MODX, и отдельно некое приложение «каталог», а сайт с каталогом пусть работает как с сервисом, по API. Это даст возможность как угодно менять схему работы каталога, писать его на любом языке, с любой БД, развернуть их на разных серверах. А сайт будет жить и работать самостоятельно. Запросы к сервису можно кешировать, для быстродействия.