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

Пригодится в мелких проектах — Лендинги, Визитки. Где нагрузка маленькая.
Специфика такова, что SqLite3 это грубо говоря БД в обычном файле и применяется лишь на шаред хостингах без поддержки серверов баз данных, например таких как mysql.
Выгода для клиента, что он будет платить меньше за хостинг.
Конечно же для высоко-нагруженных проектов он не подходит в виду своих ограничений.

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

$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