При разумном (ну не сотни или тысячи) кол-во дочерних элементов у категории — напишите небольшой сниппет, который будет формировать строку для параметра $thread в нужном формате:
&threads=`[[!buildThreads]]`
Или укажите &threads=`*`, чтобы выбирать все цепочки, а нужное ограничение задайте через параметр &where:
Если 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. Это даст возможность как угодно менять схему работы каталога, писать его на любом языке, с любой БД, развернуть их на разных серверах. А сайт будет жить и работать самостоятельно. Запросы к сервису можно кешировать, для быстродействия.
Или укажите &threads=`*`, чтобы выбирать все цепочки, а нужное ограничение задайте через параметр &where:
По идее это должно сработать.
2. В форму добавляете скрытое поле
а в чанке письма уже
событие onHandleRequest, обработчик — например Ресурс. А на странице ресурса вызвать уже сниппет некий. Задача этого сниппета — найти product, и вызвать ecForm и ecMessages, передав им соответствующий thread.
Из частых проблем — еще версию php посмотрите, на 5.3, как ни странно, на некоторых хостингах были проблемы, поднятие версии их решало.
Уже тогда думать.
При работе через аякс стили не будут подгружаться, т.к. по-умолчанию они подключатся к странице в момент вызова ecMessages, а этот момент у вас уже после того, как страница улетела в браузер.
Уберите в настройках компонента пути к файлам стилей и скриптов и подключите их вручную в шаблон сайта.
Начать можно с того, что там что-то типа облака, и бац, нет FTP (ну про ssh и заикаться не буду)!
Вот задачка то была выкачать несколько тысяч картинок с сайта, пришлось парсер сайта делать и уже им качать.
В общем буэ. Зато когда продажу разработки сайта делаешь — «фу, какие 50 тыщ, вон за 10 интернет магазин предлагают», а потом правда, как поставить событие в метрике никто не знает)
Если в id дело, то надо у форм прописывать че нить типа id=«form-[[+id]]». Если не жестко все это прописано по 10 раз в коде — то, думаю, все исправимо.
Если сложно исправить переделать, что бы каждый tab был отдельной страницей, проблема уйдет.
Ну голову включите, почему не работает) поди id у формы общий или че нить подобное, вот и срабатывает только первая.
По АПИ — да, все так поняли, не взирая на кажущуюся сложность это абсолютно рабочий способ. Издержки на лишний запрос к сервису, как правило, не очень большие. В общем подумать стоит
Если параметры для товаров едины — зачем их выносить в отдельную таблицу то?
Можно подумать вообще с точки зрения архитектуры поступить так: отдельно сайт на MODX, и отдельно некое приложение «каталог», а сайт с каталогом пусть работает как с сервисом, по API. Это даст возможность как угодно менять схему работы каталога, писать его на любом языке, с любой БД, развернуть их на разных серверах. А сайт будет жить и работать самостоятельно. Запросы к сервису можно кешировать, для быстродействия.