Зависает загрузка товаров в WooCommerce: как баг в WordPress 6.9 и теме Storefront 4.6.0 “положил” магазин

Иногда причины критических сбоев в WooCom­merce кроются там, где их совсем не ждешь. Недавно пришлось столкнуться с ситуацией, когда интернет-магазин начал непредсказуемо «тормозить», а страницы некоторых товаров и вовсе перестали загружаться, выдавая таймаут (504 Gate­way Time-out).

Симптомы выглядели классически для перегруженной базы данных, но реальная причина оказалась куда интереснее и была связана с глобальным обновлением Word­Press.

Ниже — пошаговый разбор этого кейса: от диагностики до одной строчки кода, которая всё исправила.

Симптомы: мистика со старыми URL

Проблема началась с резкого роста нагрузки на сервер. В панели управления WooCom­merce зависала загрузка карточек товаров при редактировании. На фронтенде страницы тоже могли грузиться по 20–30 секунд.

В процессе диагностики выявилась странная закономерность:

1. Создается новый вариативный товар с новым адресом (slug) — всё летает.
2. Этому же новому товару присваивается старый URL (от ранее удаленного товара, например, shu-puer-da-hu-ya) — страница намертво зависает.

Первая мысль — проблема в самом товаре, огромном количестве вариаций или сломанных метаданных.

Этап 1: Проверка базы данных и кэша

Чтобы исключить проблему с «раздутой» базой WooCom­merce, были проверены:

• Количество записей в таблицах wp_postmeta для проблемных товаров.
• Связи атрибутов в wp_term_relationships.
• Служебные таблицы WooCom­merce (wc_product_meta_lookup и wc_product_attributes_lookup).

Результат: База данных оказалась в идеальном состоянии. Дубликатов нет, количество мета-полей минимальное (около 25–30 на товар). Стало понятно, что проблема структурная, а не в объеме данных.

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

Этап 2: Детальный анализ проблемы

Для чистоты эксперимента были отключены абсолютно все плагины, кроме самого WooCom­merce. Кэширование, SEO-модули, плагины редиректов — всё деактивировано. Ошибка сохранилась.

Оставался только одна переменная которую не менял — тема оформления. На сайте использовалась дочерняя тема на базе популярной Store­front.

Переключение на другую тему решенило проблему.

Истинная причина: конфликт WordPress 6.9 и get_adjacent_post

Корень скрывался в файле темы: storefront/inc/woocommerce/class-storefront-woocommerce-adjacent-products.php

Этот класс отвечает за логику вывода соседних товаров (блоки «Предыдущий товар» / «Следующий товар»). Он модифицирует стандартный SQL-запрос Word­Press через фильтр filter_post_where.

Что произошло под капотом:

1. Вышло обновление Word­Press 6.9, в котором разработчики ядра изменили логику работы функции get_adjacent_post(). Теперь для поиска соседних записей используется не только дата публикации (post_date), но и ID записи (post_ID). Это было сделано для предотвращения багов, когда у нескольких постов одинаковая дата публикации.
2. В теме Store­front (версии 4.6.0) использовалась старая логика перехвата этого SQL-запроса.
3. Столкновение новой логики ядра WP и старого фильтра темы приводило к тому, что SQL-запрос формировался некорректно.
4. База данных уходила в бесконечный цикл (infi­nite loop) при попытке найти соседний товар. Именно поэтому зависали конкретные URL — они попадали в «слепую зону» этого сломанного запроса.

Решение

Разработчики из Automat­tic (создатели WooCom­merce и Store­front) оперативно отреагировали на проблему совместимости с новым ядром WP.

Решение заняло ровно две минуты, а найти причину часы:

1. Обновление темы Store­front с версии 4.6.0 до 4.6.2. В этом релизе файл class-storefront-woocommerce-adjacent-products.php был переписан с учетом новых требований Word­Press 6.9.
2. Сброс постоянных ссылок (Настройки -> Постоянные ссылки -> Сохранить).
3. Очистка объектного кэша (Object Cache / Tran­sients).

Сразу после обновления таймауты исчезли, нагрузка на CPU упала до штатных значений, а старые URL стали открываться за доли секунды.

Выводы

Этот кейс отлично показывает, что при внезапных «тормозах» WooCom­merce не всегда виноваты тяжелые картинки, слабый хостинг или конфликты десятков плагинов.

• Всегда проверяйте чейнджлоги (changel­ogs) обновлений ядра. Мажорные обновления Word­Press (как 6.9) часто меняют работу базовых функций.
• Тема — это такой же функциональный модуль. Если плагины обновлены, а сайт лежит, проблема почти наверняка кроется в functions.php или служебных классах активной темы.
• Симптом со старыми URL — маркер проблем с маршрутизацией или соседними записями. Если новый товар работает, а переименованный зависает — ищите причину в хуках, которые обрабатывают permalink или навигацию по соседним постам.