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

Через TicketForm это по меньшей мере странно, ибо оно другие вещи делает вообще-то.

А так возьмите html форму с нужными вам полями. Установите Formit. Напишите небольшой hook к нему в 30 строчек кода. И в нем создайте запись в поле migx.
Универсального нет решения, все индивидуально…

Ну можно по разному пробовать.
Я писал про это место:


В принципе можете попробовать и на фронте вместо title указать че нить типа [[%option_[[+name]]_title]]., т.е. сформировать из названия опции запись словаря.

Приятно расписано, подробно и по делу! думаю, продолжать стоит!

Если в название опции вписать ключ из лексикона, не сработает случайно?

[[%option_title]]

Ну тогда после синхронизации проверять такие каталоги и снимать их с публикации, скриптом по крону… или по событию синхронизации.

Глобального и простого решения «галочка в настройках» — нет.

В админке или на сайте?

У вас select попал внутрь leftJoin, а должен быть на том же уровне. Проверьте скобочки в общем.

Но почему дело касается только именно vendor?
Чего особенного в нём)!?

Без понятия, но что-то там есть, из-за чего соответствующие запросы кешируются.

Есть-ли какие-нибудь хитрости в настройках кеширования для интернет магазина на minishop2? Может где-то уже обсуждалось)!?

Аккуратная разработка и работа со встроенным кешем.

Полдня вспоминал, где я такое видел…
вспомнил. Был сайт, где аналогичная фигня, не менялся производитель.

С трудом там нашел причину.
В настройках сайта было включено кеширование базы данных, параметр cache_db

modstore.pro/packages/utilities/compiler

Сейчас вы в head напишите

{var $id = $_modx->resource.id}

а в чанке мм… допустим login вот так:

{var $id = $_modx->user.id}

вопрос, сколько времени вы будете искать почему конструкция

{$id}

неправильно работает в чанке footer?

Вот поэтому и не видны переменные за границами чанка. Ибо то, что вы хотите — это глобальные переменные, что не есть гуд.

Пользуйтесь $_modx->resource.id, это нормально, понятно, удобно.

Ну и setPlaceholder, когда это нужно.

Давно пользуюсь этим.

Именно… приходится все помнить и держать в голове постоянно эту вероятность.

Мне при схожей задаче пришлось из-за этого уйти от обновления ресурсов через процессоры, т.к. очень долго.
Все через ручную работу с объектами делал и каждый раз вспоминал, не забыл ли чего…
Зато 15 тыс объектов за 5 минут обновлялись.

Это больше вопрос к pdoTools…
но в тексте ошибки прямо написано:

Could not join TVs to the class "ecMessage" that is not a subclass of the "modResource". Try to specify correct class in the "joinTVsTo" parameter.

Попробуйте указать этот параметр!!!

А, ну и хорошо)

Да не умеет он искать нигде, кроме ресурсов и комметариев Tickets.

«Прописать» — посмотрите исходный код mSearch2, мб по аналогии с Tickets сможете внести изменения, чтобы и в других таблицах искал.

Потому что в данном коде вы сначала ищете по полям ресурса, а затем присоединяете к результату таблицу с сообщениями, но никак не ищете по ней!

Вот цитата из документации на mSearch2:

Благодаря специальному алгоритму, можно индексировать необычные поля документов, например свойства товаров miniShop2, просто указав их в настройках наравне со всеми. Также mSearch2 умеет индексировать комментарии Tickets, соответствующая настройка включена по умолчанию.

отсюда видим, что поиск может идти по полям документа и по комментариям Tickets, так mSearch2 сделан!

Смотрю base добавили и заработало)

Вот даже сформулировать проблему лень.

Ссылки генерируются относительные, без "/" в начале, отсюда и проблема вся.

Или тег base в head добавьте, или используйте параметр schema конкретно в вызове сниппета, или глобально для всего сайта. Например, вот, классная инструкция: modx.pro/howto/5139, раздел «I».