Василий Наумкин

Василий Наумкин

Был в сети 10 июня 2026, 17:44
Заказы не принимаю
Ни Evolution, ни Revolution с такой скоростью работать не должны.

Вариантов, на самом деле немного:
1. Тормозит какой-то PHP сниппет. Например, генерация меню, если оно большое. Пробуй убирать вызовы сниппетов по одному и замерять скорость.
2. На странице много плейсхолдеров, которые не могут быть обработаны и парсер крутит их по 10 раз впустую.

Судя по времени запроса к БД — у вас первый вариант.
Сервер теперь проверяет сам себя каждые 10 минут. Если сайты не отвечают в течении определённого времени, то все нужные сервисы будут перезапущены, а мне придёт уведомление, чтобы проверил как там дела.

Очень жалею, что не додумался написать такую проверку раньше.
Через несколько дней придется за деньги просить кого-то из сообщества создать такой компонент.
Компонент
Office делает так из коробки и умеет еще много чего дополнительно.

Не знаю, зачем нужно писать новый компонент.

Да и разместив его на главном репозитории и на modstore.pro, увеличится популяризация как этого сообщества, так и MODX в целом.
Нет, не увеличится, проверено много раз.

По вашему компоненту Tickets тоже будет не мало «хотелок», не сложных, но важных. Сейчас, пока, собираю их в кучу, скоро буду к Вам стучаться!
Вряд ли я чем-то смогу помочь, у меня работа расписана до следующего года.
Да, на этот раз виноват не MySQL, а PHP. Разбираюсь, принимаю меры.

Понимаю, что это звучит глупо, но сэмулировать такое никак не получается, поэтому читаю логи и пытаюсь понять, как такое могло выйти.

Если у кого есть желание переехать на более свободный сервер H4 — пишите в техподдержку хостинга, организую.
Так мы и делаем это на каком-нибудь фреймворке — MODX.

Если вдруг (вдруг) с ним что-то случится, то уже сделанные решения всё равно будут работать, никуда не денутся.

Если есть желание тащить на себе альтернативную ветку — в добрый путь. Я не потяну.
Но вот где выставить время их хранения? Найти не могу. Нужно что бы лежали «вечно» пока их либо не удалят, либо не оформят.
Товары хранятся в сессии. Пока жива сессия, в ней будут лежать товары.

Параметры сессии живут в настройках системы.
В методе getChunk его просто негде указывать, но можно написать свой сниппет, который будет запускать pdoTools, менять в нём tplPath и возвращать $pdoTools->getChunk(имячанка);

Дальше всё примерно так же:
{$chunk = $_modx->runSnippet('getChunk', [
	'chunk' => 'mychunk.tpl',
	'tplPath' => '/my/path/'
])}
С одной стороны, может и непривычно, но зато правильно — ведь фильтруются товары, а не категории, и ты видишь сколько всего остаётся именно товаров.

В принципе, можно расширить и переписать все фильтры, чтобы выводились цифры категорий, но это очень трудозатратно и бессмысленно. Гораздо лучше и скрыть это дело, чтобы никого не смущать.

Категорий обычно не очень много, так что показ предсказаний им не нужен.
As I see, resource2formit checks resource id in the $_GET array, but you specifying it in the parameter &resId. And you specifying not an id, but link to current resource.

So, you need to remove &resId from FormIt call and load edit form with an id at the $_GET. For example, your link for create a new resource can be
http://mysite.com/ad/resource
And for update it must be:
http://mysite.com/ad/resource?resId=15

Than you need to fix your snippet resource2formit. Just replace
else {
		if ($field == "[[+fi.IMAGE]]" & $docarray[$field] !== null) { 
			$hook->setValue($field,$docarray[$field]);
		}
	}

to
else {
		$hook->setValue($field,$docarray[$field]);
	}

After this your snippet will set [[!+fi.id]] placeholder and you will be able to update an existing resource.