Воеводский Михаил

{$_pls['placeholder']}

{$_pls['tvname']}

Сделай стоимость такого билета на 1 рубль меньше. Фактически, ни на чем не отразится, но в таблице легко заметишь.

{$_modx->resource.tvname}

И сейчас все побегут массово расширять все системные таблицы )))

HybridAuth.

Второе. Когда необходимо постоянно работать с некоторыми TV, появляется смысл добавить дублирующие значения в основную таблицу. В противном случае это не нужно.

Не исчезнут, Office дополняет.

MinifyX ошибки в своей работе скидывает в лог ошибок MODX. Что там есть?

Вот и поглядим, знают ли они русские народные пословицы :)

О 3 версии уже года 3 идут разговоры.

Сергей, молодец!
Все гениальное просто :) Твой пытливый ум еще много полезностей, чую, придумает )))

Отправить AJAX запрос из браузера, отловить запрос сниппетом или плагином, запустить обработку. После всего этого вызвать JS метод Order.getCost();

Ровно так :)

Стоимость считается на фронте на JS?
Если так, необходим собственный класс доставки, который принимает стоимость из браузера, но очень это криво выглядит. Нужно больше подробностей.

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

<?
switch ($modx->event->name){
	case 'msOnBeforeAddToCart':
		if (!is_array($options)) $options = json_decode($options, true);
		if (isset($options['price'])) {
			$product->set('price', $options['price']);
		}
		break;
}

Кусок с работающего проекта. Полагаться на записанное в options товара никогда не нужно, но как пример хорошо подходит.

1) Использовать getIterator
2) Перед сохранением установкой новых значений и сохранением в базу проверять, есть ли изменения. Если не изменилось, ничего не делать.

Это самая очевидная оптимизация. Следующий шаг — начальная выборка значений в виде массивов данных, без getCollection/getIterator. Сравнить все на уровне массивов, затем быстро пройти только по изменившимся товарам.

И, кстати, рекомендую именно проверку на уровне массивов сделать с формированием нового массива, в котором будут изменившиеся значения. На мой взгляд, быстрее этого варианта только чистый SQL. Могу, конечно, ошибаться.

В такой задаче, хоть и не самый правильный способ, я бы смотрел в сторону обновления на чистом SQL, если нет необходимости отработки плагинов и прочего при изменении товаров. А такой необходимости нет, учитывая допустимость работы без процессоров.

Что касается самих процессоров, с ними быстрее не получится. Они, помимо getObject() и save() выполняют еще огромное количество функций и проверок.

У вас товары сохраняются все и всегда? Или есть проверка на изменившиеся поля?

Спасибо!