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

Во первых у пользователя есть доп поле properties, оно даже в админке редактируется.

Но лучше сделать отдельную таблицу для связей. Будет потом проще выборки делать.

article наверное сработает, там уж ms2form нужно смотреть, никогда не пользовался им.

Из разумных вариантов весь список url загнать в .htaccess

Может быть попробовать компонент Redirector, но я не знаю, как он себя поведет с url, которые содержат get параметр.

Для производителей (vendor) есть отдельная таблица, нужно в нее записи вносить, а товару id записи.

Можете плагин написать для автоматизации сиего действия. При создании категории в корневом разделе — морозить url.

Ну да.
1. Устанавливаете настройку use_frozen_parent_uris
2. Для всех разделов «Кухни», «Столовые» и т.д. замораживаете url без /katalog/

Думается, что здесь или на Tickets накручивать…

Но если проект взрослый — лучше собственный компонент.

Через 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, когда это нужно.

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

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