Все ID и классы оберток присутствуют?
По умолчанию должно быть так:

<div id="pdopage">
    <div class="rows">
        [[!pdoPage?
            /// параметры
        ]]
    </div>
    [[!+page.nav]]
</div>

Что-то типа этого (бэкап базы только сделайте):

<?php
$tvid = 123; // ID TV-шки
$vendor = 'Производитель' // Название производителя
$template = 6; // ID шаблона товара

$sql = "SELECT * FROM {$modx->getTableName('modTemplateVarResource')} WHERE tmplvarid = {$tvid}"; 
$q = $modx->prepare($sql);
$q->execute();
$tvs = $q->fetchAll(PDO::FETCH_ASSOC);
foreach($tvs as $tv) {
	if($tv['value'] != $vendor) continue; // если название не то, пропускаем
   	if(!$resource = $modx->getObject('modResource', array('id' => $tv['contentid'], 'template' => $template)) continue; // если нет ресурса с таким ID и шаблоном, пропускаем
	$resource->remove(); // удаляем ресурс
}

Там на компоненте уже года два пометка на удаление стоит.
Насколько я знаю, Женя давно задумал seoFilter Pro и опять же есть некое наитие, что работа скоро начнется.

Спасибо все встало без проблем. Крутая подборка.
Но есть одни вопрос как поставить плагин

Code Snippet

уже все перерыл не появляется иконка.

Спасибо

Я бы подошел к вопросу с другой стороны.
А в какой момент вам нужны эти данные?
Если просто запустить какой-то отдельный скрипт и сделать свои дела — одно.
Если вам нужно взаимодействовать с объектами MODX и, например, проверять уровень привелегий, доступов и прочей ереси, то через MODX.
А сниппет — это тот же php, но вызванный где-то в середине страницы. В этом случае можно сразу вызвать в сниппете. Если, допустим данные которые будут отображены снипетом очень долго получаете, то иногда люди делают через ajax загрузку, чтобы сэкономить время загрузки основной страницы.
Те вы понимаете, что просто отвечать на ваш вопрос не получиться, необходимо знать еще и место и «куда чего-данные».

так а где пакет-то купить можно?

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

В консоли ничего нет, в админке тоже пусто.

Уберите Fenom синтаксис из значения параметра pageLinkScheme, напишите как в доке.

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

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

Так вот чтобы не было тормозов я и решил ввести limit, нам же не принципиально очистить таблицу за один проход.

А в smartSessions медленная работа, думается, обусловлена LIKE поиском по колонке user_agent во время очистки и отсутствием индекса))) нужно добавить

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

Чуть может не понял, но приведу рассуждения. Поправь, если я не прав.

Рассматриваю ситуацию, когда базе у тебя 2 000 000 сессий, из них 1 400 000 (70%) — эт боты.
Т.е. симулируется картина, что либо сессии продолжительное время вообще не очищались и накопились, либо у сайта ну очень высокая посещаемость.

В первом случае, если мы поставим limit 5000, то эти сессии удалятся за 280 подходов. Ну а далее у нас будет регулярно все это работать и 2 млн сессий в базе уже не будет. По идее мы должны так сконфигурировать сервер, чтобы каждый раз при срабатывании gc() устаревало не более 5000 сессий, иначе они начнут накапливаться.

Во втором случае (если бешеная посещаемость), хватит ли лимита в 5000 для того, чтобы удалить старые сессии? А если нет — то мы должны повысить лимит.

И у меня возник вопрос: какая разница в обоих случаях, есть лимит или нет? Кроме первых 280 проходов, которые без лимит выполнились за 1 раз (напомню в нестандартной ситуации, что сессии ранее не очищались).

p.s. про smartSessions:
А в smartSessions медленная работа, думается, обусловлена LIKE поиском по колонке user_agent во время очистки и отсутствием индекса))) нужно добавить. Я когда это писал все — тормозов особо не заметил, посещаемость сайтов моих была ну до 1000 человек в сутки. Но вообще, поле is_bot реально лучше, ибо в этом случае LIKE поиск убирается, остается просто быстрый поиск по колонке tinyint. В общем если руки дойдут — изменю алгоритм.

Плохая практика отвечать вопросом на вопрос. Артур, пожалуйста пишите по существу! У нас версия старая: MODX Revolution 2.8.3-pl.

Я ему PR зашлю

SeoFilter надеюсь будет работать и с FlatFilters.

Я тебя умоляю, @Евгений Шеронов даже не знает о существовании твоего компонента. И под него что-то делать точно не будет. Он вообще с MODX не работает.

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

мне кажется большинство их меняет, с целью безопасности

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

Что касается развития, то оно будет в ближайшие недели, только только ни функционала поиска, ни функционала SeoFilter не будет. Поиск в mSearch2 хорошо работает. SeoFilter надеюсь будет работать и с FlatFilters.

у тебя я так понимаю так же можно вылечить modx.pro/components/24542#comment-142272

Отписываюсь по тестированию, тестировал
— на modhost.pro/ на тарифе разработка, сгенерировал 500 000 записей уникальных сессий с 70% ботов.
— выделенный сгенерировал 2 000 000 записей уникальных сессий с 70% ботов.

Далее по тексту режим:

standart — стандартный запрос на удаление что используется в modSessionHandler

$this->modx->removeCollection(Session::class, [
    'access:<' => time() - $this->gcMaxLifetime
]);

ext — запрос на удаление что используется в ExtSessionHandler

Сразу стало заметно тормоза:
Session cleanup time for mode «standart»: 0.0150 s
Session cleanup time for mode «ext»: 3.3543 s

Был один запрос с несколькими условиями github.com/vgrish/ExtSession/blob/490dfc4a7a8f1d1dd18a988573f5b607fadc457c/core/components/extsession/src/ExtSessionHandler.php#L180-L204

Разбил на несколько, стало чуть получше но все равно не то.
Добавил общий индекс на 3 колонки github.com/vgrish/ExtSession/blob/8223ff63e5574b8697fcf0eb66e55c93eaba7fd6/core/components/extsession/schema/extsession.mysql.schema.xml#L36-L40

Session cleanup time for mode «ext»: 1.3543 s — Тоже не фонтан.

Перекинул колонки github.com/vgrish/ExtSession/blob/8223ff63e5574b8697fcf0eb66e55c93eaba7fd6/core/components/extsession/schema/extsession.mysql.schema.xml#L8-L10 перед колонкой data

Стало еще получше.
Ну и подумал нам же не надо прям сразу за раз удалять все записи, пускай удаляет в несколько проходов и добавил к удалению LIMIT.

И вот тут уже стало совсем хорошо
Session cleanup time for mode «ext»: 0.0029 s

Так что с помощью тестов удалось найти слабое место и исправить ситуацию. LIMIT Подбирается опытным путем в зависимости от посещаемости сайта и мощности сервера. По умолчанию использовал 5000.

После инсталляции:

[Tue Feb 13 17:36:03 2024] [error] [client 5.142.177.134:0] PHP Fatal error: Uncaught Error: Class «uagent_info» not found in /home/p/prozon/new.prozon.ru/sys/cache/includes/elements/modplugin/41.include.cache.php:194\nStack trace:\n#0 /home/p/prozon/new.prozon.ru/sys/model/modx/modscript.class.php(76): include()\n#1 /home/p/prozon/new.prozon.ru/sys/model/modx/modx.class.php(1674): modScript->process(NULL)\n#2 /home/p/prozon/new.prozon.ru/sys/model/modx/modresponse.class.php(83): modX->invokeEvent('OnWebPagePreren...')\n#3 /home/p/prozon/new.prozon.ru/sys/model/modx/modrequest.class.php(138): modResponse->outputContent(Array)\n#4 /home/p/prozon/new.prozon.ru/sys/model/modx/modrequest.class.php(122): modRequest->prepareResponse()\n#5 /home/p/prozon/new.prozon.ru/sys/model/modx/modx.class.php(1461): modRequest->handleRequest()\n#6 /home/p/prozon/new.prozon.ru/public_html/index.php(54): modX->handleRequest()\n#7 {main}\n thrown in /home/p/prozon/new.prozon.ru/sys/cache/includes/elements/modplugin/41.include.cache.php on line 194, referer new.prozon.ru/adm/?a=workspaces

Что-то первое знакомство не задалось(
Решил установить на сайт (у сайта изменены пути) при установки оба компонента SendIt и flatfilters, assets установились в нужную папку (она у меня по другому называется) а вот core создал свою папку core. Не беда перенес в ручную) Конфик появился, могу его создать, НО не могу удалить и не могу и проиндексировать. В логах ошибка Uncaught (in promise) SyntaxError: Unexpected end of JSON input at functions.min.js:1:188
На чистую систему не ставил, сказать будет работать или нет, не могу. Если все должно работать как на видео, то это круто. Но хотелось бы развития и увидеть функционал SeoFilter и может даже какой ни будь умный поиск.
И да у SendIt почему-то по умолчанию стоит путь assents (мне кажется большинство их меняет, с целью безопасности).

Это очень хорошо, спасибо ?

Сделал, выложил!