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

Весь where — это второй параметр при вызове функции. Так что указывать нужно вот так:

<?php
$pdo = $modx->getService('pdoFetch');
$resources = $pdo->getCollection('modResource',
	array(
		'parent' => 9,
		'published' => false
	),
	array(
		'limit' => 3,
		'sortdir' => 'DESC',
		'processTVs' => true,
		'tvPrefix' => 'tv.' 		
	)
);

Ни Evolution, ни Revolution с такой скоростью работать не должны.

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

Судя по времени запроса к БД — у вас первый вариант.

modx.pro/components/5433-tickets-version-161pl-user-ratings/

Уверен, что именно

$period['$cost']

а не

$period["$cost"]

Второй вариант с двойными кавычками не будет работать.

На нашем хостинге, хотя-бы, всегда можно найти виноватого (меня) и поругаться.

Это редкая возможность для любого сервиса =)

Думаю, что никак — нужно писать самостоятельно.

Документация по Plupload вот здесь.

Сервер теперь проверяет сам себя каждые 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/'
])}

Конечно:

{$chunk = $_modx->getChunk('@FILE my_chunk.tpl')}

Файл my_chunk.tpl должен лежать в MODX_ASSETS_PATH. 'elements/chunks/', то есть, по умолчанию, в /assets/elements/chunks/.

С одной стороны, может и непривычно, но зато правильно — ведь фильтруются товары, а не категории, и ты видишь сколько всего остаётся именно товаров.

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

Категорий обычно не очень много, так что показ предсказаний им не нужен.

Не подскажу.

Напиши мне письмо на bezumkin@ya.ru

Это я о том, что нигде не видел никаких ограничений на путь для загрузки конфига.

У нас они загружаются без симлинков. Возможно, у тебя просто был неверный путь или что-то с правами.

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.