Когда фильтры WooCommerce начинают показывать неверное количество товаров, пропускают вариации или ведут себя по-разному после массового импорта, проблема может быть не в самом виджете фильтра. В современных версиях WooCommerce для ускорения выборки по атрибутам используется служебная таблица wc_product_attributes_lookup.
Это денормализованный индекс данных об атрибутах товаров. Если он не успел обновиться, повреждён после миграции или не соответствует текущим товарам, layered navigation и другие механизмы каталога могут возвращать неожиданный результат. Решение — не очищать таблицу вручную, а проверить её состояние и использовать штатную регенерацию WooCommerce.
Зачем WooCommerce отдельная lookup table
Каталог WooCommerce хранит товары, термины атрибутов, связи taxonomy и вариации в нескольких WordPress-таблицах. Выполнять сложные JOIN для каждого фильтра дорого, особенно на большом магазине. Поэтому WooCommerce поддерживает отдельную таблицу lookup, где данные подготовлены для более быстрых запросов каталога.
В официальной документации по базе WooCommerce wc_product_attributes_lookup описывается как таблица данных атрибутов продуктов, используемая для layered navigation и фильтрации. Это индекс, а не единственный источник правды: исходные товары и атрибуты остаются в стандартных структурах WordPress/WooCommerce.
Типичные симптомы рассинхронизации
- фильтр по цвету или размеру не показывает товар, хотя атрибут назначен;
- после импорта атрибут виден в карточке, но отсутствует в фильтре;
- счётчики товаров в фильтрах не совпадают с фактическим каталогом;
- вариативный товар появляется при прямом поиске, но теряется в layered navigation;
- после массового обновления товаров фильтры временно дают старые результаты;
- после миграции базы поведение фильтров отличается от старого сайта.
Эти симптомы не доказывают, что виновата именно lookup table. Перед регенерацией проверьте, что нужный атрибут действительно глобальный, назначен товару, используется для фильтрации и товары опубликованы/видимы в каталоге.
Сначала проверьте состояние таблицы
WooCommerce предоставляет отдельную группу WP-CLI команд wc palt для Product Attributes Lookup Table. Это безопаснее ручных DELETE/INSERT, потому что команды используют внутреннюю логику WooCommerce.
На сервере с WP-CLI начните с информации:
wp wc palt infoКоманда помогает увидеть состояние механизма lookup. Доступные подкоманды также включают включение/отключение, регенерацию и работу с отдельными товарами. Набор опций зависит от установленной версии WooCommerce, поэтому перед запуском полезно вызвать wp help wc palt.
Когда нужна полная регенерация
Полная перестройка оправдана после миграции, массового импорта, восстановления базы или подтверждённой рассинхронизации. Для этого штатный CLI поддерживает:
wp wc palt regenerateНа большом каталоге операция может быть ресурсоёмкой. Не запускайте её в пик продаж без оценки количества товаров, PHP memory, времени выполнения и фоновых очередей. Лучше сначала повторить процедуру на staging и зафиксировать длительность.
Регенерация одного товара
Если проблема касается нескольких карточек, не обязательно перестраивать весь каталог. WooCommerce CLI предусматривает регенерацию данных для конкретного товара. Это особенно полезно при отладке импорта или кастомного обновления продукта.
Синтаксис и параметры лучше брать из wp help wc palt regenerate_for_product для вашей версии WooCommerce. Идея проста: сначала исправить источник данных товара, затем перестроить его lookup-запись и проверить фильтр.
Почему ручная очистка таблицы — плохой первый шаг
wc_product_attributes_lookup — производная таблица, поэтому кажется, что её можно просто очистить и заполнить заново SQL-скриптом. Но штатный процесс WooCommerce учитывает варианты товаров, visibility и механику обновления. Самописная перестройка легко создаёт новый рассинхрон.
Кроме того, на живом магазине полупустая таблица во время ручного rebuild может временно сломать фильтрацию. Штатные команды и фоновые процессы проще контролировать и повторять.
Вариативные товары требуют отдельной проверки
Наибольшее количество странных случаев возникает с вариациями. Атрибут может быть назначен родительскому товару, конкретным вариациям или одновременно участвовать в создании вариаций и отображении каталога. После регенерации проверяйте не только родительскую карточку, но и реальные комбинации вариаций.
Для теста выберите товар с несколькими цветами/размерами и последовательно проверьте: карточку, архив категории, один фильтр, комбинацию двух фильтров и наличие товара после очистки кэша.
Связь с импортами и синхронизациями
Если проблема возвращается после каждого импорта, регенерация лечит только последствия. Нужно проверить, каким способом импорт обновляет атрибуты: через WooCommerce CRUD, REST API, прямые SQL-запросы или собственный код.
Прямое изменение term relationships и post meta в обход WooCommerce может не запустить нужные процессы обновления индекса. Для постоянной интеграции лучше использовать официальные CRUD/API методы или после пакетной операции явно инициировать штатную синхронизацию.
Кэш тоже может маскировать результат
После регенерации пользователь может продолжать видеть старый каталог из page cache, object cache или CDN. Поэтому проверка должна отделять состояние базы от кэша. Очистите только нужные уровни кэширования и сравните ответ в приватном окне или через прямой запрос без cached HTML.
Если магазин использует persistent object cache, полезно проверить его настройки. Для больших каталогов мы отдельно разбирали Redis Object Cache в WooCommerce.
Как проверить результат после rebuild
- Выберите 5–10 товаров с разными наборами атрибутов.
- Зафиксируйте ожидаемые результаты фильтра до работ.
- Выполните штатную регенерацию.
- Очистите релевантный object/page cache.
- Проверьте фильтр по одному атрибуту.
- Проверьте комбинацию нескольких атрибутов.
- Проверьте вариативные товары и out-of-stock настройки.
- Сравните скорость и SQL-нагрузку каталога.
Что ещё может ломать фильтры
- кастомная тема переопределяет query каталога;
- фильтр стороннего плагина использует собственный индекс;
- атрибут создан как custom product attribute вместо глобальной taxonomy;
- товар скрыт из каталога или отсутствует в stock;
- кэш отдаёт старую страницу;
- импорт не использует WooCommerce CRUD;
- плагин поиска/фильтрации хранит дополнительный индекс и требует свой rebuild.
Поэтому успешный wc palt regenerate — не повод сразу считать проблему решённой. Если результат не изменился, надо смотреть запрос конкретного фильтра.
Производительность большого каталога
Lookup table ускоряет типовой путь WooCommerce, но сама по себе не решает все проблемы каталога. На магазинах с десятками тысяч товаров важны индексы MySQL, object cache, качество theme queries, число JOIN, вариации и стратегия фильтрации.
Если фильтр работает правильно, но отвечает медленно, сначала профилируйте SQL и PHP. Не стоит постоянно запускать regenerate как «оптимизацию»: это обслуживающая операция, а не ускоритель каждого запроса.
Чек-лист безопасного восстановления
- создан backup базы;
- процедура проверена на staging;
- подтверждено, что проблема связана с product attributes lookup;
- используется штатный
wp wc palt, а не ручной SQL rebuild; - для большого каталога выбран период низкой нагрузки;
- проверены вариативные товары;
- после rebuild очищен релевантный кэш;
- проверены фильтры и счётчики на реальных категориях;
- если проблема повторяется, исправлен импорт или интеграция-источник.
Когда лучше не делать rebuild самостоятельно
На магазине с большим трафиком, сложными импортами и сторонними фильтрами регенерация может совпасть с другими фоновыми задачами и создать лишнюю нагрузку. Если неизвестно, какой индекс фактически использует фильтр, сначала нужна диагностика.
A.S Groups выполняет доработку WooCommerce, диагностику каталогов, импортов и фильтров, а также оптимизацию запросов и фоновых процессов. Для постоянного сопровождения можно подключить техническую поддержку WordPress/WooCommerce.
Обсуждение
Вопросы и комментарии
Можно уточнить детали статьи или поделиться своим опытом. Первый комментарий проходит проверку.