Точно

Была такая же проблема. Снес его нафиг и перенес все в autoRedirector.

Набросал схематический вариант, посмотреть можно здесь: s5885.test.modx.pro/index.php?id=5 (доступ s5885/VPdm-g7Y6zKf), плагин QuickOrder.
Код плагина:

<?php
$context = $modx->context->get('key');
if ($context == 'mgr' || empty($_POST['quick_order']) || empty($_POST['id']) || empty($_POST['customer'])) {
	return;
}
/**
 * @var miniShop2 $miniShop2
 */
$miniShop2 = $modx->getService('minishop2');
$miniShop2->initialize($context, array(
	'json_response' => false,
));
if (!($miniShop2 instanceof miniShop2)) {
	return;
}
$_POST['customer'] = array_merge(array(
	'delivery' => 1,
	'payment' => 1,
), $_POST['customer']);
foreach (array('email', 'phone', 'delivery', 'payment') as $field) {
	$response = $miniShop2->order->add($field, $modx->getOption($field, $_POST['customer'], ''));
	if (empty($response['success'])) {
		return;
	}
}
$response = $miniShop2->cart->clean();
if (empty($response['success'])) {
	return;
}
$response = $miniShop2->cart->add($_POST['id'], $modx->getOption('count', $_POST, 1), $modx->getOption('options', $_POST, array()));
if (empty($response['success'])) {
	return;
}
$miniShop2->order->submit();
$modx->sendRedirect($modx->makeUrl($modx->resource->get('id')));

Ещё вопрос. Как изменить modX::LOG_LEVEL с LOG_LEVEL_ERROR на LOG_LEVEL_WARN?
В противном случае предупреждения не попадают ни в логи php, ни в логи modx (в настройках php включены все логи: E_ALL | E_STRICT).

В настройках ничего похожего нет.
Можно, конечно, в плагине на OnLoadWebDocument и OnManagerPageInit, но это не кошерный вариант, т.к. плагин придётся вешать и на многие другие события (почти на все).

…

…

Собственно всё, разобрался!

aq/index.php?question=15 на раздел1/раздел2/чуп.html
Сделал так
RewriteEngine On
RewriteCond %{QUERY_STRING} =question=15
RewriteRule ^faq/index\.php /раздел1/раздел2/чуп.html? [R=301,L]

Работает! Может кому-то будет полезно.

Всем спасибо ))))

Выяснил, что Redirector перестаёт отдавать 404 ошибку как только добавляю ссылки такого типа faq/index.php?question=15
В итоге сделал через .htaccess, причём сработала только такая конфигурация:
RewriteRule ^page1.php page2.html [R=301,NC,L]

Подскажите, как сделать редирект через .htaccess вот таких ссылок
faq/index.php?question=15 на раздел1/раздел2/чуп.html

Никак не могу найти вариант для MODX.

Да и вообще, это же бета, ведь будут тарифы с большим объемом?

Конечно!

Технически нас ничего не ограничивает, можно хоть отдельный сервер выделить для одного сайта — было бы желание.

да, один был не нужный, остальные это архивы с файлами, которые продаются через my.digiseller.ru, юзер оплачивает, и файл скачивается с сервера… криво конечно… в дальнейшем хочу, чтобы все через сайт продавалось, но не знаю как этот механизм сделать, чтобы скачивалось при оплате, но ссылку он не видел :) Есть куча мелочей, изображений, от старого сайта, там по мб не очень много но все же буду чистить. Да и вообще, это же бета, ведь будут тарифы с большим объемом?

1. Да, если НЕ очищать кэш munee при очистке кэша modx, тормозов нет.
2. Если вручную удалить кэш munee (.../core/cache/default/munee), получаем тормоза.
3. Если оставить всю структуру папок и подпапок кэша munee, а кэш-файлы .css и .js из этих подпапок удалить, то по-прежнему наблюдаются тормоза.

Вывод: большой расход времени — из-за пересоздания всех кэш-файлов при первом запуске munee.

Вот сейчас всё понятно, откуда берутся цифры 0,2-0,7 сек (без очистки кэша modx) и 3-5 сек после очистки кэша modx. В первом случае обновляется только кэш одного файла (который изменился), во втором случае обновляются кэши всех файлов, которые передаются MinifyX/munee (их у меня 13 штук). Т.е. получаем разницу в 13 раз:
[0,2-0,7 сек] * 13 = [3-5 сек]
Всё сходится.

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

Спасибо :)

спасибо, класно все видно. Ухх надо чистить, как то размахнутся я :(

Копаться в исходниках munee?

Я ссылки дал на исходники MinifyX, а не munee. Плагин MinifyX удаляет директорию с кэшэм munee при очистке кэша всего сайта в админке. При первой генерации страницы munee заново генерирует свой кэш, и видимо это у тебя и тормозит.

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

Поэтому, на мой взгляд, проблемы никакой нет. Если так сильно не нравится очистка кэша munee — закомментируй её в плагине, ссылка выше была уже дана.

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

Копаться в исходниках munee? Ну уж нет. Чего он там делает при первом вызове после очистки кэша — это пусть остаётся на его совести. В любом случае, без корректировки исходников его поведение не изменить. Посему то, что я сделал — единственный вариант минимизации этих проявлений для текущей версии minifyX/munee.

На данный момент вход завязан на магазин, так что сменить email можно только сразу и там и там.

Но в будущем (сегодня-завтра) вход мы отвяжем и появится передача сайтов на другой аккаунт (это попозже).

Доброго дня! Если я хостинг регистрирую на себя, могу ли я перерегестировать созданный аккаунт на другое лицо, сменить e-mail и т.п. (предполагается, что это требуется для передачи сайта заказчику)? Если нет, то планируется ли подобное в будущем?

Обожемой!

В версии 1.2.2 не очищается родной кэш munee, а в 1.3.0 — очищается. Вот и вся разница.

Запись файлов и вычисление хэша на скорость практически не влияют, так что ты просто надстроил свой велосипед над моим.

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

Как ни странно, я считаю, что если ты чистишь весь сайт, то кэш munee тоже должен удаляться.