22 мая 2026, 21:53
Разумно. Все поля подряд не хочу добавлять в чанк. Практика показывает, что полей очень много, содержимое может быть объемным и появление подсказок мо...
mSearch - обновление до версии 1.3.0. 2
22 мая 2026, 18:30
Это changelog разросся. Не помещается в базе данных mariaDB (mysql почему то съедает и не морщится) Выпустил Версию. 1.11.1 с решением этой проблемы.
MiniShop3 1.11.0 8
22 мая 2026, 09:51
Твой бот стримит всё что происходит в терминале? И умеет выполнять слэш команды для агентов типа /status /btw? А ещё нет ли проблемы разрастания входя...
[aiAssist] Я же просто попросил его создать магазин, а он СДЕЛАЛ ЭТО! 16
19 мая 2026, 04:04
Сделал новую версию с табами и возможностью запуска сразу для всех вариантов.
Сначала содержимое для технического ресурса откуда будет запускаться вы...
VersionX переполнил базу данных 8
18 мая 2026, 13:46
Исправление уже готово github.com/modx-pro/MiniShop3/pull/271
MiniShop для MODX3. Что происходит и когда ждать? 53
17 мая 2026, 13:31
При включении компонента, все теги, снипеты и вызовы на fenom — на фронте выводятся текстом без обработки
[xDevPicker] Редактируем чанки с фронтенда в один клик 5
16 мая 2026, 12:23
Если кто-то использует счетчики, например, Яндекса, то это должно быть отражено в политике конфиденциальности и для них тоже нужно брать согласие поль...
Плашка о использовании cookie файлов на сайте 11
Всего 125 920 комментариев
что они не удаляются?
По умолчанию должно быть так:
Насколько я знаю, Женя давно задумал seoFilter Pro и опять же есть некое наитие, что работа скоро начнется.
Но есть одни вопрос как поставить плагин
уже все перерыл не появляется иконка.
Спасибо
А в какой момент вам нужны эти данные?
Если просто запустить какой-то отдельный скрипт и сделать свои дела — одно.
Если вам нужно взаимодействовать с объектами MODX и, например, проверять уровень привелегий, доступов и прочей ереси, то через MODX.
А сниппет — это тот же php, но вызванный где-то в середине страницы. В этом случае можно сразу вызвать в сниппете. Если, допустим данные которые будут отображены снипетом очень долго получаете, то иногда люди делают через ajax загрузку, чтобы сэкономить время загрузки основной страницы.
Те вы понимаете, что просто отвечать на ваш вопрос не получиться, необходимо знать еще и место и «куда чего-данные».
В консоли ничего нет, в админке тоже пусто.
Значение параметра не обрабатывается парсером, а просто заменяются плейсхолдеры.
пока идет запрос удаления новый пользователь не получит новый идентификатор сессии, уже действующий пользователь тоже словит задержку и будет нервно курить и в итоге закроет сайт.
Так вот чтобы не было тормозов я и решил ввести limit, нам же не принципиально очистить таблицу за один проход.
да, это ускорит удаление, но не сильно, в случае с большим кол-ом данных думаю будут те же тормоза что я описал выше.
Рассматриваю ситуацию, когда базе у тебя 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. В общем если руки дойдут — изменю алгоритм.
Переименовывать папку с асетами для безопасности это нонсенс, к ней в любом случае есть доступ с фронта, как её не назови.
Что касается развития, то оно будет в ближайшие недели, только только ни функционала поиска, ни функционала SeoFilter не будет. Поиск в mSearch2 хорошо работает. SeoFilter надеюсь будет работать и с FlatFilters.
— на modhost.pro/ на тарифе разработка, сгенерировал 500 000 записей уникальных сессий с 70% ботов.
— выделенный сгенерировал 2 000 000 записей уникальных сессий с 70% ботов.
Далее по тексту режим:
standart — стандартный запрос на удаление что используется в modSessionHandler
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.