Очистка WooCommerce без потери заказов: sessions, transients и логи

Когда WooCommerce-магазин работает месяцами или годами, в базе и файловой системе накапливаются временные данные: transients, записи сессий, журналы ошибок и следы фоновых задач. Иногда они действительно мешают диагностике или занимают лишнее место. Но команда «очистить базу» опасна, если не разделять временный кэш, активные корзины и данные заказов.

Безопасная очистка WooCommerce начинается не с SQL-запроса, а с определения типа данных. Expired transients можно удалять штатно, product/shop transients — пересоздавать при необходимости, а Clear customer sessions нельзя воспринимать как обычную уборку: официальный инструмент WooCommerce удаляет данные всех активных клиентских сессий, включая содержимое корзин.

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

Сначала разделите данные по назначению

Шаг 1. Сделайте резервную копию и зафиксируйте состояние

Даже если планируется только удаление expired transients, на production-магазине полезно иметь свежую резервную копию базы. Это особенно важно, если параллельно устанавливались плагины очистки, мигрировало HPOS-хранилище или кто-то ранее запускал прямые SQL-запросы.

Перед обслуживанием зафиксируйте хотя бы количество последних заказов, состояние checkout, наличие активных фоновых задач и размер основных таблиц. Если магазин использует HPOS, не считайте, что все заказы живут в wp_posts и wp_postmeta: современный WooCommerce может хранить их в специализированных таблицах. Отдельно этот переход разобран в статье про совместимость WooCommerce HPOS.

Шаг 2. Очистите expired transients, а не всё подряд

WordPress Transients API предназначен для временного кэширования. У transient может быть срок действия, после которого запись считается истёкшей. WooCommerce в разделе WooCommerce → Status → Tools имеет отдельный инструмент Expired Transients, который удаляет истёкшие временные данные WordPress.

Это принципиально отличается от удаления всех transient-записей. Если задача — плановое обслуживание, разумнее начинать именно с expired data. Так вы не уничтожаете актуальный кэш, который ещё используется сайтом.

Если на сервере доступен WP-CLI, WordPress документирует команду:

wp transient delete --expired

Перед использованием полезно проверить, где вообще хранятся transients:

wp transient type

При постоянном object cache, например Redis или Memcached, поведение хранения отличается от обычной базы: WordPress может направлять Transients API в object cache. Поэтому бессмысленно оптимизировать wp_options по шаблону из чужой инструкции, не посмотрев реальную конфигурацию.

Чем WooCommerce Transients отличаются от Expired Transients

В системных инструментах WooCommerce есть отдельная команда WooCommerce Transients. По официальному описанию она очищает временные данные, связанные с магазином и товарами. Это кэш, который WooCommerce может построить заново.

Такой инструмент полезен после изменений каталога, цен, атрибутов или при подозрении на устаревший кэш. Но запускать его каждый час «для ускорения» нет смысла: после очистки часть данных придётся вычислить повторно. Если магазин медленный постоянно, нужно искать источник нагрузки — запросы к базе, плагины, внешний API, cron, object cache или тяжёлый frontend.

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

Шаг 3. Не путайте stale sessions с кнопкой Clear customer sessions

Самая опасная ошибка — увидеть большое количество WooCommerce sessions и нажать Clear customer sessions в рабочее время. Официальная документация прямо указывает: этот инструмент удаляет активные клиентские сессии, включая содержимое корзин. Отдельная документация WooCommerce о длине cart session также поясняет, что эта команда немедленно истекает корзины пользователей.

Поэтому массовая очистка всех customer sessions — не «безопасная уборка». Её можно рассматривать как диагностическую или аварийную операцию, когда вы понимаете последствия, выбрали подходящее окно и готовы потерять текущие анонимные корзины.

Если сессии копятся ненормально, правильнее выяснить, почему штатная очистка не успевает: работает ли WP-Cron, выполняются ли Scheduled Actions, нет ли постоянно падающей фоновой задачи. Для этого есть отдельный разбор WP-Cron и Action Scheduler в WooCommerce.

Что делать, если таблица сессий большая

Не начинайте с TRUNCATE и не удаляйте строки по случайному условию из статьи пятилетней давности. Сначала определите:

• растёт ли таблица постоянно или это разовый всплеск;
• есть ли большой объём действительно активных сессий;
• работает ли автоматическая очистка;
• нет ли бота, который массово создаёт новые сессии;
• не сломан ли cron;
• нет ли кастомного кода, который меняет срок жизни сессии.

На крупном магазине размер таблицы сам по себе не доказывает проблему. Важнее динамика роста, количество запросов к ней и влияние на checkout.

Шаг 4. Настройте логи, а не удаляйте их вслепую

WooCommerce хранит журналы в WooCommerce → Status → Logs. Часть логов, например fatal-errors, формируется автоматически, а журналы некоторых платёжных шлюзов и расширений появляются только после включения logging в их настройках.

В актуальной системе логирования WooCommerce можно выбрать хранение в файловой системе или базе. Файловое хранение используется по умолчанию; для live-сайта WooCommerce отдельно не рекомендует переключать общий logger на database storage без причины. В настройках также есть Retention period — срок хранения старых записей; документация указывает значение по умолчанию 30 дней.

Практический вывод: вместо ручного удаления каталога wc-logs или строк из таблицы логов настройте разумный retention. Перед уменьшением срока сохраните журналы, которые ещё нужны для расследования оплаты, возвратов, интеграции доставки или внезапных fatal errors.

Action Scheduler: чистить логи можно только после проверки очереди

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

Откройте Scheduled Actions и отдельно проверьте failed, долго висящие pending и повторяющиеся hooks. Если сначала удалить историю, а затем искать причину, диагностика станет сложнее. Особенно это важно для экспорта заказов, отправки писем, подписок, синхронизации склада и webhooks.

Что нельзя удалять в рамках обычной очистки

Техническое обслуживание не должно затрагивать рабочие сущности магазина. Не удаляйте массово:

• заказы и order meta;
• HPOS order tables;
• клиентов и user meta;
• order items и данные оплат;
• webhook-конфигурацию;
• download permissions без понимания бизнес-правил;
• Scheduled Actions только потому, что их много;
• options с непонятными префиксами.

Особенно опасны универсальные «database cleaner» плагины, которые предлагают одним кликом удалить orphaned или unknown data. То, что запись кажется неиспользуемой плагину, не означает, что её не читает собственная интеграция или кастомный код.

Нужен ли прямой SQL

В большинстве плановых случаев — нет. Для transients, системных кэшей и логов WooCommerce уже имеет штатные механизмы. Прямой SQL стоит применять только после резервной копии, точного понимания схемы и проверки выборки через SELECT.

Если всё же требуется собственная процедура для очень большой базы, сначала сделайте её на staging и ограничьте удаление строгим условием. Не используйте команды вроде DELETE FROM wp_options WHERE option_name LIKE '%transient%' как универсальный рецепт: они обходят логику API, могут затронуть неистёкшие значения и не учитывают object cache.

Как проверить магазин после очистки

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

1. Откройте каталог и несколько карточек товара.
2. Добавьте простой и вариативный товар в корзину.
3. Перейдите между страницами и убедитесь, что корзина сохраняется.
4. Откройте checkout и пересчитайте доставку/налоги, если они используются.
5. Создайте тестовый заказ подходящим способом.
6. Проверьте письмо, статус заказа и интеграции.
7. Посмотрите свежие WooCommerce logs и Scheduled Actions.

Если после обслуживания появились пустые корзины, ошибки checkout или новая очередь failed actions, не продолжайте очистку. Сначала найдите связь с выполненной операцией.

Когда очистка действительно помогает

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

Но если магазин тормозит из-за медленного API, тяжёлого фильтра, неоптимального SQL, большого autoload, некорректного Redis или проблем PHP-FPM, очистка даст максимум временный эффект. В таком случае нужен технический аудит с измерением времени запросов и проверкой реальных узких мест.

Когда лучше не чистить production самостоятельно

Если база большая, магазин принимает заказы круглосуточно, подключены CRM/склад/доставка, используется HPOS или есть кастомные таблицы, безопаснее сначала воспроизвести процедуру на staging. Особенно это важно, если предыдущая «оптимизация» уже приводила к пропаже корзин или рассинхронизации заказов.

A.S Groups может провести аудит и доработку WooCommerce: найти, что именно разрастается, проверить cron и журналы, подготовить резервный сценарий и протестировать checkout после обслуживания. Для обсуждения конкретного магазина можно написать через страницу контактов.

Официальные источники

• WooCommerce System Tools — назначение WooCommerce Transients, Expired Transients и Clear Customer Sessions.
• WooCommerce System Status Report — разделы Tools и Logs.
• WooCommerce Developer Docs: Logging — storage, retention и уровни журналирования.
• Change the default cart session length — поведение клиентских сессий и массовой очистки корзин.
• WP-CLI: wp transient — просмотр и удаление expired transients.