Наумов Алексей

Ну они плавающие, я не знаю, в чем причины. Я провел некоторую оптимизацию компонента, может что-то и исправилось

А что за настройка то у источника файлов?

Вот посмотри код, я вижу что проверка внутри объекта modMediaSource и там проверяется именно системная настройка upload_maxsize

А баг ли это?.. какая настройка важнее, глобальная или то, что указано в источнике файлов?

Да, выпустил обновку. TODO в коде оказывается с самого начала на этот момент висел.

Сначала нужно вернуть настройку session_handler_class на modSessionHandler, и только потом удалять компонент, так должно быть все нормально

У pdoResources есть параметры prepareTVs и processTVs.

msProducts просто тащит то, что записано в БД, а там путь относительно источника файлов.

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

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

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

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

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

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

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

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

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

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

modstore.pro/packages/utilities/smartsessions

так?.. только обрати внимание, я условия поменял для примера.

'where' => [
    ["status" => 0, "date1:<" => "2024-02-23"],
    ["OR:status" => 1, "date1:>" => "2024-02-23"]
],

Ну что, спасибо! Выглядит красиво и свежо!!!

Прям по запросу «minishop2 2.8.6 превью» в гугл первые ссылки же:
modx.pro/help/24315
modx.pro/help/24339
modx.pro/news/24265

Привет, ну да, верно написал Николай, ошибка из-за того, что один запрос еще не завершен, а система отправляет второй. Посещаемость большая? Ошибка частая или разок проскочила?
Я, когда руки дойдут до smartSessions, попробую оптимизировать компонент, может побыстрее будет работать.

Смотрим стандартный htaccess (если сервер apache, конечно).

Видим, что все запросы направляются на index.php.

Меняем на myscript.php, делаем чё хотим.
Делаем include index.php

Получили:

Хотелось бы сделать так, чтобы все команды в PHP файле выполнялись до всех инициализаций в MODX.

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

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

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

Рассматриваю ситуацию, когда базе у тебя 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. В общем если руки дойдут — изменю алгоритм.

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