Алексей Смирнов

А вы напишите так:

$q = "EXPLAIN SELECT...";
$out = $modx->query($q)->fetchAll(PDO::FETCH_ASSOC);
print_r($out);

1. В MODX есть автометки, которые подхватывают значения, которые уже были использованы на сайте.
2. Если у вас готовые списки, то у ТВ полей есть поле — Варианты значений — туда можно вписывать значения или руками или специальным сниппетом, ипользуя любой алгоритм.

попробуйте написать сниппет с прямым запросом в БД для подсчета.
Скорее всего это будет быстрее срабатывать.
Или как вариант — добавить TV поле в которое записывать заранее Значение при обновлении ресурса ну и тянуть это ТВ поле запросом.

Еще проверьте .htaccess на отсутствие редиректов с http на HttpS.
Пробовали ли:
без S написать ИЛИ:
Еще проверяйте все с браузера в ИНКОГНИТО режиме. тк сам браузер может кешировать редиректы любые.
Долго писал. Вы уже и решили проблему. Успехов!

Ну тут нужно следующее учесть:
1. После обновления системы у Ваши вмешательства с БД скорее всего полетят.
2. Если вы хотите в site_content использовать свои, в ручную добавленные поля, то погуглите — есть решения через плагины (только так не надо делать, да и вообще трогать site_content).
3. Лучше сделать расширение таблицы site_content, как это сделано, например в minishop2. А тк вы используете minishop2, то почему вы не используете ОПЦИИ??? они как раз для подобных целей — идеальны.
4. mSync — не знаю точно как работает, но знайте одно, если у вас кол-во товаров начинает превышать 10...20 тыс, то Вам скорее всего необходимо писать свой вариант mSync притом скорее всего на прямых запросах через modx--qwery. Это сложнее, но вы сможете быстро делать то что вам нужно.
4.1. Если товаров планируется более 20… 30 тыс, то имейте в виду, что добавление товара с ростом их общего кол-ва приводит к постепенному снижению производительности операций на чтение и запись этих товаров, особенно это чувствуется после сброса кеша и особенно при импорте-экспорте стандартными средствами. И тут или смотреть в сторону других Систем или Учить mysql + php или обратиться к профильным разработчикам, которые учтут нагрузки и прочие нюансы.

Наверное я успел намечтать что должно быть из коробки пока читал… Я просто тоже подумываю о шаблонизации MODX оглядываясь на CMS системы. И даже подготовил для себя личную архивную сборку. 1 раз довелось поработать с платным шаблоном на Джумле и то что я увидел меня впечатлило. И шаблоны Битрикса меня разбаловали, хотя они подороже но и функций море… Сейчас вот пишу строки и понимаю что в общем-то ценник за то, что экономится куча времени на рутинную настройку — это прям плюс. Посему думаю, что цена как раз в порядке… Да и шаблон по Вашим словам будет развиваться — это здорово. Кажется это может повлиять на распространение MODX Revo в положительную сторону в СНГ. Успехов!

Посмотрел на тестовом.
Крутое решение, но кажеццо что ценник сильно завышен…
Нашел мелкий баг. в списках товаров отображение в строку нет ссылки на товар… А в по-блочной все ок.

У меня при 100т ресурсов + 2 TV поля в индексе (всего около 8,5 мл строк) поиск с использованием mSearch2 если искать 1 слово распространенное (любовь) находит 30 тыс ресурсов — примерно за 30...40 сек. Если искать менее распространенное слово, например розетка, общее время посика 5 сек… (VPS у меня), но при выводе еще время тратится на сам вывод (там 1 рес + 4 TV).
Думаю, если вы хотите максимальной производительности, то на готовых решениях не будет все комфортно. Советую делать свои таблицы и поиск (а лючше посмотреть поиск в сторону специализированных решений, например Sphinx).

К сожалению проект в производстве, поэтому уже удалил 2ю версию компонента.
Ошибок в логе небыло, лишь после нажатия на «Добавить в избранное» ничего не происходило, а в консоли браузера писалась (самим скриптом) error… (2 слова).
Ошибку отправляет класс на сколько я сумел влезть в код: класс (public function processResource($rid = 0)) в файле msfavorites.class.php. Точнее не отправлял а не давал сработать компоненту.
А у меня подчиненные ресурсы отдают редирект таким кодом:

//$sendok  - url главного товара.
 $modx->sendRedirect($sendok,array('responseCode' => 'HTTP/1.1 301 Moved Permanently'));

этот код в снипете на странице конкретного товара.
Если этих данных достаточно, то ок. Иначе чуть позже на тестовом воссоздам ситуацию.

Если ограничить глубину вывода настройкой depth=0 (первый уровень) должны попасть только дочерние ресурсы.
А так не совсем ясна структура:
1) Если у вас к обьекту привязан итем (их может быть несколько?), и фильтровать вам нужно по 3м полям на конкретной странице (Название обьекта, название Итема, год обьекта), то mSearch2 справится с минишопом или без него.
2) Если у вас какая-то другая структура, то опишите. т.к. не ясно к чему принадлежит Название компании — это итем или обьект.
P.S. Collection хорош тем что вы можете в ручную вбивать TV значения прямо в списках ресурсов, чего не сделать в самом минишопе и что затрудняет быстродействие простых операций заполнения в ручную.

Хорошее и полезное дополнение.
Но пришлось откатиться на первую версию компонента (благо покупал давно и осталась) т.к. во 2й существует сейчас непреодолимая вещь:
У меня в ручную реализованы схожие товары и есть ведомый товар, который доступен, остальные товары (связанные) отдают 301 редирект на главный товар (страницы товаров со своими ID). Так вот при попытке добавить связанные товары — появляется ошибка в консоли js. и все. Как только убираю редиректы со связанных товаров — все работает.
Убил день на то чтобы понять это…
Зачем проверять доступность ресурса по ID — мне не ясно.
Есть просьба убрать эту проверку или как-то сделать ее выключаемой, т.к. думаю могут в перспективе быть подобные проблемы у людей (хотя сомневаюсь — наверное я единственный ))) ) но все же.
Спасибо.

Я редактировал сам сниппет, скопировав его, т.к. штатного отключения для пагинации нет.
Видимо, нужно, сильно попросить Василия добавить пару нужных вещей для TicketComments, т.к. с пагинацией есть проблемы.
убрать форму можно вмешавшись в код дополнения строки около 190:

$pls = array('thread' => $scriptProperties['thread']);
if (!$Tickets->authenticated && empty($allowGuest)) {
    $form = $pdoFetch->getChunk($tplLoginToComment);
} elseif (!$Tickets->authenticated) {
    $pls['name'] = $_SESSION['TicketComments']['name'];
    $pls['email'] = $_SESSION['TicketComments']['email'];
    if (!empty($enableCaptcha)) {
        $tmp = $Tickets->getCaptcha();
        $pls['captcha'] = $modx->lexicon('ticket_comment_captcha', $tmp);
    }
    $form = $pdoFetch->getChunk($tplCommentFormGuest, $pls);
} else {
    $form = $pdoFetch->getChunk($tplCommentForm, $pls);
}
if ($_GET['page']) {
    $form = ''; // очищаем переменную если есть GET запрос пагинации. Т.е. форма на страницах 2 и более не появится.
}
$commentForm = $thread->get('closed')
    ? $modx->lexicon('ticket_thread_err_closed')
    : $form;
$output = !empty($formBefore)
    ? $commentForm . $commentsThread
    : $commentsThread . $commentForm;

У этого решения есть минус — при прямом обращении к странице комента — форма не будет показана. Поэтому это всего лишь временное не полноценное решение.

Заказывайте 17 июля. массово замечно 19 числа… -1 день на всякий случай. можно и 15го.

Вам скорее всего поможет слдедующее modxclub.ru/topics/massovyie-vzlomyi-modx-revolution-2792.html
там заплатка на POST запросы… хотя бы так:

Есть простой патч, конкретно против этой уязвимости в начало 2-х файлов прописать.
//connectors/system/phpthumb.php

//fstr patch CVE-2018-1000207
if(isset($_POST["cache_filename"]) && strpos($_POST["cache_filename"],".php") ) die();


//assets/components/gallery/connector.php

//fstr patch2 CVE-2018-1000207
if(isset($_POST["action"]) && $_POST["action"] =="web/phpthumb" && isset($_POST["f"]) && (strtolower($_POST["f"])=="php") ) die();

Последняя версия какая у вас стояла?

Так же обновляйте Gallery до последней — заплатка появилась!

Врядли под раздачу, тк. например на сайте что я лечил — запрос сразу непосредственно на системный конектор phpthumb с POST запросом! А следом еще один запрос на файл dbs.php, те скрип проверяет получился ли взлом… тк я успел до ночи обновить сайт и gallery то на 2й файл сервак уже отдал 404-ю т.е. взлом не получился. А потом через 4 часа повторынй запрос к конектору, но тут уже поинтересней чутка. сначала опять на системный конектор а потом на конектор gallery. следом проверили файл assets..images..accesson.php (который должен был появится в результате взлома) получили 404.
Обратил внимание что шлют POST запросы.
Так что «товарищи» которые писали прогу для взлома прекрасно понимали что хотят взломать.
И лечение обновить modx До последней версии + gallery до последней Очень даже актуально и спасло!

Дополню по следам:
в корневой директории файлы dbs.php cache.php.
так же местами присутствует файл в корне annizod.
На одном сайте где стояла древняя 2.3.1 в логах заметил что стучались через коннектор phpthumb
и сразу пошли обращения на левые файлы…

2. обновляется ядро до последней 2.6.5

Новая волна взломов подобного плана.
На одном сайте где стояла древняя 2.3.1 в логах заметил что стучались через коннектор phpthumb
Вариант лечения (в идеале)
1. Выкатывается недавний бекап.
2. обновляется ядро до последней 2.6.4 (с 2.3.1 на 2.6.4. прошло все хорошо). заметил что 2.5.1 версия так же заражается. 2.5.4, 2.5.8. — пока под вопросом.
3. БД пока не заметил что трогает. вроде чиста.
Признаки вируса:
в корневой файлы dbs.php cache.php. Все JS на сайте обнуляют на какой-то код, поэтому JS тоже нужно весь менять. (каспер ругается страшно на эти js)
так же местами присутствует файл в корне annizod.
Если у кого еще есть инфа — трогает ли этот вирус БД — дайте знать. Спасибо.
Учитывая масштаб — вирусяка автоматическая.