У меня работает.

Версия 2.8.3

Это чанк, а сниппет я не знаю как найти

Да, таблицу чистил вручную по вхождениям сигнатур ботов)

Спасибо. Но ничего не выводится, ошибок в логе нет.
Я создал сниппет «GetPrice»:

<?php
$tablePrefix = $modx->getOption('table_prefix');
$sql = "SELECT Product.pagetitle AS name, Data.price AS price, Parent.pagetitle AS parent FROM {$tablePrefix}site_content Product
LEFT JOIN {$tablePrefix}ms2_products Data ON Product.id = Data.id 
LEFT JOIN {$tablePrefix}site_content Parent ON Product.parent = Parent.id
WHERE Product.class_key = 'msProduct'";
$statement = $modx->query($sql);
$products = $statement->fetchAll(PDO::FETCH_ASSOC);
$output = [];
foreach ($products as $product) {
    $output[$product['parent']][] = $product;
}

Затем вывожу в чанке:

{set $menu = 'GetPrice' | snippet}
{foreach $menu as $parent => $products}
    <p>{$parent}</p>
    <ul>
    {foreach $products as $data}
        <li>{$data.name} - {$data.price}</li>
    {/foreach}
    </ul>
{/foreach}

И ничего. Помогите пожалуйста разобраться.

странные ошибки

база то в порядке? таблица жива?

честно говоря не помню, там и есть то пара их: что вообще включено, и делитель, у меня наверное 1/100 стоит

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

Так вы Наверное попали в сети 2.8.6 версии MODX. там проблема с фотками. нужно повышать версию php до 8.
ИЛи менять одну строчку в коде pthumb и оставаться на 7.4.
На 8й версии php MODX и пакетах могут быть так же ошибки, поэтому пока совет по стабильности 7.4 + поправить строку в phumb или
Установить 2.8.5 и не обновлять пока ее и радоваться жизни без проблем.

Файл проверки, как уже писал, прописать в index.php корня сайта. Страница с капчей — отдельный HTML файл. При попадании под фильтр, показываю страницу капчи (код выше). В общем, к примеру, если при открытии страницы сайта попадается что-то подозрительное, то это подозрительное отправляется на проверку.

В сниппете я его не нашёл, а это чанк

И такие ошибки:

[2024-02-26 20:25:30] (ERROR @ /www/core/xpdo/xpdo.class.php : 988) xPDO->removeCollection - Error deleting smartSession instances using query DELETE FROM `modx_smart_sessions` WHERE  ( `modx_smart_sessions`.`access` < '1708957438' AND `modx_smart_sessions`.`user_agent` LIKE '%YandexMarket%' )  
[2024-02-26 20:25:42] (ERROR @ /www/core/xpdo/xpdo.class.php : 988) xPDO->removeCollection - Error deleting smartSession instances using query DELETE FROM `modx_smart_sessions` WHERE  ( `modx_smart_sessions`.`access` < '1708957460' AND `modx_smart_sessions`.`user_agent` LIKE '%YandexTurbo%' )  
[2024-02-26 20:25:53] (ERROR @ /www/core/xpdo/xpdo.class.php : 988) xPDO->removeCollection - Error deleting smartSession instances using query DELETE FROM `modx_smart_sessions` WHERE  ( `modx_smart_sessions`.`access` < '1708957502' AND `modx_smart_sessions`.`user_agent` LIKE '%YandexBot%' )  
[2024-02-26 20:25:56] (ERROR @ /www/core/xpdo/xpdo.class.php : 988) xPDO->removeCollection - Error deleting smartSession instances using query DELETE FROM `modx_smart_sessions` WHERE  ( `modx_smart_sessions`.`access` < '1708957420' AND `modx_smart_sessions`.`user_agent` LIKE '%DataForSeoBot%' )

И выдает вот такие ошибки:

[2024-02-26 19:43:34] (ERROR in xPDOConnection::connect @ /www/core/xpdo/xpdo.class.php : 3125) SQLSTATE[HY000] [2002] No such file or directory
[2024-02-26 19:43:34] (ERROR @ /www/core/xpdo/om/xpdoobject.class.php : 263) Error preparing statement for query: SELECT `smartSession`.`id` AS `smartSession_id`, `smartSession`.`access` AS `smartSession_access`, `smartSession`.`ip` AS `smartSession_ip`, `smartSession`.`user_id` AS `smartSession_user_id`, `smartSession`.`user_agent` AS `smartSession_user_agent`, `smartSession`.`data` AS `smartSession_data` FROM `modx_smart_sessions` AS `smartSession` WHERE `smartSession`.`id` = ?  - 
[2024-02-26 19:43:34] (ERROR in xPDOConnection::connect @ /www/core/xpdo/xpdo.class.php : 3125) SQLSTATE[HY000] [2002] No such file or directory
[2024-02-26 19:43:34] (ERROR in xPDOConnection::connect @ /www/core/xpdo/xpdo.class.php : 3125) SQLSTATE[HY000] [2002] No such file or directory
[2024-02-26 19:43:34] (ERROR @ Unknown0) PHP warning: Unknown: Failed to write session data using user defined save handler. (session.save_path: /var/lib/php/sessions)

Сигнатуры прописаны.

Благодарю за ответ. У вас эти настройки PHP (gc) как выставлены?

Ну а сигнатуры то ботов нужных прописаны в настройках (smartsessions_bot_signatures)?
Это довольно индивидуальный параметр для каждого сайта. Если не очищается совсем — то gc не работает в php, с ним нужно копать, вот чтиво десятилетней давности: bezumkin.ru/sections/tips_and_tricks/2422

Алексей, а что делать, если таблица не очищается от сессий ботов? Хотя для ботов стоит время 10800.

Да, полностью согласен с этим. Компонент нужный. Вы молодец :))

Я вообще зачем дополнение сделал:
У моего сайта была посещаемость 300 человек в сутки. В неделю это 7*300=2100 человек. Сессии как раз неделю и хранились. Вот только в таблице сессий было не 2000 записей, как было бы ожидаемо, а около 100-200 тысяч. Когда я начал изучать вопрос — боты, одни боты! яндекс, гугл, просто wget какие-то, индексаторы картинок, парсеры… чего только не было) и что забавное — почти всегда каждый запрос генерил новую сессию, боты не держали её)) а итоге приходит яндекс бот на сайт, индексирует сайт, 3000 страниц — о-ппа и +3000 сессий. А кому они нужны?)

Поле access есть: см. исходники.

… таблица начинает расти в прогрессии, если есть много контекстов

В этом дополнении нет ничего нового, связанного с контекстами, по сравнению со стандартным sessionhandler. Основная цель дополнения — расширить таблицу сессий, чтобы в ней хранился user-agent. И если user-agent принадлежит боту — чистить такие сессии раньше, не хранить их долго.

И нужно исключить возможность вот такой ошибки :)

Эта ошибка возникла из-за того, что оказался поврежден файл с таблицей БД. Причина, по которой произошла данная ситуация, вероятно, связана с каким-то сбоем на сервере. К примеру, у меня раньше часто из-за нехватки памяти падал процесс mysql, и эти падения иногда заканчивались повреждением отдельных таблиц БД, весьма часто таблицы с сессией (потому что эта таблица каждый раз при открытии любой страницы сайта обновляется), но иногда и таблиц вроде site_content. Увеличение объема памяти решило в моем случае проблему с падающим mysql и повреждением таблиц.