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

А самый правильный — интерфейс ISessionHandler с методом flushSessions, от которого наследуется уже modSessionHandler, и что бы именно он вызывался в процессоре.

Просто не выйдет…
MODX не умеет очищать сессии, если используется иной, отличный от modSessionHandler класс.

В процессоре проверяется настройка session_handler_class, и если там указано что-то не стандартное — сразу ошибка.

Как вариант — сделать свой пункт в меню для очистки сессий, а стандартный скрыть… ну и тогда нужно дописать процессор и т.п.

Точно, будем фиксить в следующих версиях)

А что выводит?

print_r($scriptProperties);

Так вот компонент и решает задачу:
1. отдельно управлять временем жизни сессий для авторизованных пользователей (например, поставить им месяц);
2. отдельно управлять временем жизни сессий ботов (к примеру, поставить им 3 часа);
3. У всех остальных — ну пусть будет стандартная неделя.

И на моих сайтах, за счет п.2. размер таблицы и объем данных уменьшился в десятки раз, т.к. именно сессии различных ботов составляли 90% записей в таблице.

Что значит только для авторизованных?..
А корзина товаров? А если я товар «отложил», а если я перешел по реферальной ссылке на сайт, а если у нас правда что-то работает через ajax?
Правильнее бы конечно создавать сессии когда они действительно нужны. Но MODX работает на своей волне, а кажется именно его мы здесь и обсуждаем.

Более разумно просто отказаться от использования таких дополнений как AjaxForm, который для каждого посетителя создает сессию.

Давайте делать статичные странички на html!

Так у меня и только beta версия только выпущена)))
Но за здравую критику — спасибо

Может быть, да)
но код в посте на 90% взят с минишопа, а написан он уже несколько лет назад

{$_modx->runSnippet('mapexMap', [
		'resource' => '8',
               'tvName' => 'ИМЯ ВАШЕГО TV ПОЛЯ',
		'width' => '100%',
		'height' => '460px',
		'mapId' => 'mapexMap1'
])}

Если исходные фото большие — то ms2Gallery может пережимать их на стороне клиента и фактически на сервер придет уже другой файл, в этом разница при загрузке через API и через интерфейс.

А почему думает что дубли… наверное алгоритм так срабатывает) Эту проверку можно выключить в настройках.

Это же код пример?
Просто 'id' => 'resource_id' выглядит странно :)

Какой вывод у responce?

Ну сначала быстро копируем все старые цены во временную таблицу, без разбора.
А потом уже неспешно «перебираем» эту таблицу, сравниваем со второй таблицей, где хранятся только те цены, что действительно изменились. Ну и после сравнения принимаем решение о переносе цены из временной таблицы в постоянную

Наверное, только вариант с хранением изменившихся цен.

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

Подчищает пусть каким-нибудь хитрым sql запросом.., чтобы не объекты xpdo (мы же про modx говорим?))) дергать, а попроще как-нибудь. Типа выбрать 2 последние записи с одним id товара, если цена одинаковая — то последнюю из этих записей удалить, как не нужную, а если цены разные — предпоследнюю пометить как «проверенную» и больше ее не проверять.

Или например разнести все это по 2м таблицам: одна временная, где все 40 тыс записей, а во вторую уже попадают только действительно изменившиеся цены.

В качестве element указан сниппет migxLoopCollection, он умеет работать с Fenom то вообще?..

В чанке loft-site2:
1. {$lotnumber} — верная запись
2. {$_modx->resource.lotnumber} — конечно же нет, $_modx->resource это ТЕКУЩИЙ РЕСУРС
3. [[+lotnumber]] — верная запись
4. {$_modx->getPlaceholder('lotnumber')} если в плейсхолдер никто ничего не устанавливал — то он пуст.

п.1. возможно не работает, т.к. это migx поле, там наверняка есть скобки { } и парсер Fenom на них спотыкается… может сразу в массив это преобразовать?
Вот так выводит что-нибудь?

{$lotnumber | fromJSON | print}

мейби влияет разделитель значений у mFilter2, он по-умолчанию — запятая, а она у вас встречается в значении свойств, что и может привести к косякам.

Здесь нужно понимать, как работает парсер MODX. Это именно ПАРСЕР, а не шаблонизатор.
Он сначала ВСЕ парсит, а потом выполняет условия. Т.е. TicketComments вызывается всегда, каким бы ни был parent в вашем If.
Либо в отдельный шаблон убирайте, либо переводите сайт на шаблонизатор Fenom, который уже условия обрабатывать более привычно для человеческого восприятия.

Здесь
Часть кода можно убрать отключив редактор (настройка tickets.enable_editor).
Подключение основного скрипта без правки исходников не сделать.

Обновится не выйдет 100%.
Поэтому делаете новый сайт, а старые данные импортируете через базу, csv файлы или как умеете.

Цена товара в корзине сохраняется, поэтому да, если поменять ее на сайте — в корзине будет старая.

Думаем, как поправить…
Нужно при каждом получении корзины (это плагин на событие msOnGetStatusCart, доступен объект $cart) пробегаться по корзине, получать товары и актуализировать цену.
Примеров с тем, как в корзине что-то менять — на сайте полно)