Товары WooCommerce не показываются гостям: что проверить и как исправить

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

Удобный порядок диагностики:

товар → прямая ссылка → каталог → гость/администратор → кеш → ограничения → запрос товаров → WooCommerce → тема и плагины

Вы добавили новый товар в WooCommerce, в админке он есть, а на сайте обычные посетители его не видят. Иногда проблема выглядит ещё страннее: если войти в WordPress как администратор, последние товары отображаются нормально, но в режиме инкогнито или на другом устройстве их нет.

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

Удобный порядок диагностики:

товар → прямая ссылка → каталог → гость/администратор → кеш → ограничения → запрос товаров → WooCommerce → тема и плагины

1. Сначала подтвердите проблему именно как гость

Не начинайте с настроек WordPress.

Сначала откройте одну и ту же страницу в двух состояниях:

1. в браузере, где вы авторизованы как администратор;
2. в режиме инкогнито, где нет авторизации WordPress.

Лучше проверить сразу три URL:

• страницу магазина;
• категорию, в которой должен находиться товар;
• прямую ссылку на сам товар.

Например:

https://example.com/shop/
https://example.com/product-category/category-name/
https://example.com/product/product-name/

Теперь сравните результат.

Товар есть по прямой ссылке, но его нет в каталоге

Если гость открывает страницу самого товара, но товар отсутствует в магазине или категории, значит сам товар доступен.

Искать проблему нужно в:

• видимости в каталоге;
• настройке остатков;
• фильтрах;
• блоке вывода товаров;
• shortcode;
• кастомном запросе;
• кеше страницы каталога.

Прямая ссылка тоже недоступна гостю

Если администратор открывает товар, а гость по той же ссылке получает 404, страницу входа или сообщение об ограничении доступа, сначала проверяйте:

• статус публикации;
• приватность;
• плагины ограничения доступа;
• membership/wholesale-функциональность;
• кастомный код для авторизованных пользователей.

Гость видит старые товары, но не видит последние

Это особенно важный симптом.

Если старый каталог отображается правильно, но новые товары появляются только у администратора, одним из первых подозреваемых становится кеш HTML.

Авторизованный администратор часто получает страницу напрямую от WordPress, тогда как гость может получать сохранённую ранее копию страницы из page cache, серверного кеша или CDN.

Поэтому в таком сценарии не нужно начинать с переустановки WooCommerce. Сначала сравните кешируемую и некешируемую версии страницы.

↑ К оглавлению

2. Проверьте статус публикации и Catalog visibility

Откройте проблемный товар в WordPress.

Проверьте, что товар действительно опубликован, а не находится в одном из состояний:

• Draft;
• Pending review;
• Private.

Особенно внимательно проверьте Private.

Приватный товар может быть доступен администратору или редактору и при этом недоступен обычному посетителю. Внешне это очень похоже на проблему «я товар вижу, а покупатели — нет».

Дальше проверьте Catalog visibility.

Для обычного товара, который должен быть доступен в магазине и поиске, используется вариант вроде:

Shop and search

Другие режимы меняют место появления товара:

Shop only
Search only
Hidden

Если установлен Hidden, товар может открываться по прямой ссылке, но не попадать в обычный каталог.

Это удобно использовать как диагностический признак:

прямая ссылка работает
+
в каталоге товара нет
=
проверяем Catalog visibility и сам запрос каталога

Если на сервере есть WP-CLI, состояние конкретного товара можно проверить без интерфейса WordPress.

Сначала узнайте ID товара, затем выполните:

wp eval '
$p = wc_get_product(123);

if (!$p) {
    echo "Product not found\n";
    return;
}

echo json_encode([
    "id"                 => $p->get_id(),
    "name"               => $p->get_name(),
    "status"             => $p->get_status(),
    "catalog_visibility" => $p->get_catalog_visibility(),
    "stock_status"       => $p->get_stock_status(),
], JSON_PRETTY_PRINT | JSON_UNESCAPED_UNICODE);
'

Вместо 123 укажите ID проблемного товара.

Для обычного опубликованного товара результат может выглядеть примерно так:

{
    "id": 123,
    "name": "Название товара",
    "status": "publish",
    "catalog_visibility": "visible",
    "stock_status": "instock"
}

Если здесь уже видно:

status = private

или:

catalog_visibility = hidden

сначала исправьте это и только потом переходите к более глубокой диагностике.

↑ К оглавлению

3. Проверьте остаток и скрытие товаров не в наличии

Следующая простая причина — статус наличия.

Откройте:

WooCommerce → Settings → Products → Inventory

и найдите настройку скрытия товаров, которых нет в наличии.

Если включено скрытие Out of stock товаров, WooCommerce может исключать их из клиентского каталога.

После этого откройте сам товар и проверьте:

• включено ли управление запасами;
• количество;
• Stock status;
• настройки вариаций, если товар вариативный.

Особенно важно разли чать две ситуации.

Товар виден только в админке WordPress

Если под словами «администратор видит товар» имеется в виду список:

Products → All Products

это ещё не означает, что WooCommerce обязан показывать его покупателю.

Товар может существовать в базе, но иметь:

Out of stock

и одновременно попадать под настройку скрытия отсутствующих товаров.

Товар виден на витрине именно авторизованному администратору

Если вы открываете одну и ту же страницу магазина на frontend и:

администратор → товар есть
гость → товара нет

одного только наличия уже недостаточно для объяснения.

Тогда особенно внимательно проверяйте:

• кеш;
• правила видимости по ролям;
• membership/wholesale-плагины;
• кастомный PHP-код.

↑ К оглавлению

4. Проверьте HTML-кеш: частая причина для последних товаров

Сценарий:

добавили товар
↓
администратор его сразу видит

↓
гость видит старую страницу

очень похож на кеширование HTML.

На WordPress-магазине кеш может существовать сразу на нескольких уровнях:

браузер
↓
WordPress cache plugin
↓
server page cache
↓
Nginx / FastCGI / Varnish / LiteSpeed
↓
CDN
↓
Cloudflare

Чистить всё подряд не нужно.

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

Проверьте заголовки ответа

На сервере или локальном компьютере выполните:

curl -sI https://example.com/shop/

Или оставьте только наиболее интересные заголовки:

curl -sI https://example.com/shop/ \
  | grep -Ei '^(cache-control|age|cf-cache-status|x-cache|x-litespeed-cache|x-varnish):'

В зависимости от инфраструктуры можно увидеть, например:

CF-Cache-Status: HIT
Age: 420

или:

X-LiteSpeed-Cache: hit

или заголовок другого серверного кеша.

HIT обычно означает, что ответ был взят из кеша этого конкретного слоя.

Но обратное неверно: отсутствие специального заголовка ещё не доказывает отсутствие кеширования.

Проверьте, присутствует ли новый товар в HTML для гостя

Лучше искать не название, а уникальный URL товара.

Например:

curl -sL https://example.com/shop/ \
  | grep -F '/product/new-product/'

Если команда ничего не выводит, сервер действительно отдал HTML без этого товара.

Теперь важно понять, почему: WooCommerce его исключил или вам отдали старую копию страницы.

Очистите только нужный кеш и повторите тест

Если используется кеширующий плагин:

1. очистите page cache;
2. снова откройте страницу в инкогнито;
3. повторите curl;
4. проверьте появление товара.

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

Дальше нужно выяснять уже не «почему WooCommerce не выводит товар», а:

почему кеш не инвалидируется после публикации или обновления товара.

Простое постоянное нажатие кнопки Purge проблему не решает.

Cloudflare

Обычное использование Cloudflare само по себе ещё не означает, что HTML магазина кешируется.

Но HTML может кешироваться, если настроены:

• Cache Rules;
• APO;

• другие правила edge cache.

И здесь разница между администратором и гостем становится особенно показательной.

Авторизованный WordPress-пользователь имеет cookies авторизации, а системы кеширования часто обходят HTML-кеш для таких запросов. Гость этих cookies не имеет и получает кешируемую версию.

Получается:

администратор → свежий origin HTML
гость → старый cached HTML

Если на HTML страницы магазина вы видите:

CF-Cache-Status: HIT

и именно в этой версии отсутствуют новые товары, проверяйте правила Cloudflare и механизм purge.

Не включайте без разбора кеширование всех страниц WooCommerce.

Динамические страницы вроде корзины, checkout и личного кабинета требуют отдельного отношения к кешу.

↑ К оглавлению

5. Проверьте плагины, которые скрывают товары от гостей

Если кеш исключён, следующий вопрос:

нет ли на сайте намеренного правила, которое показывает разные товары разным пользователям?

Такое поведение умеют создавать плагины:

• wholesale;
• membership;
• B2B;
• private store;
• catalog mode;
• role-based pricing;
• product visibility;
• ограничения по стране;
• ограничения по категории;
• персонализация каталога.

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

Проверьте настройки проблемного товара, его категории и соответствующего плагина.

Ищите правила примерно такого смысла:

guest → hide
customer → show
wholesale → show
logged-in only
specific roles

Особенно показательный тест:

1. открыть каталог гостем;
2. войти обычным аккаунтом покупателя;
3. открыть тот же каталог;
4. войти администратором;
5. сравнить результаты.

Если получилось:

Guest          → товара нет
Customer       → товар есть
Administrator  → товар есть

это уже мало похоже на обычный кеш.

Ищите правило авторизации или роли.

Если:

Guest          → товара нет
Customer       → товара нет
Administrator  → товар есть

проверяйте приватность товара, capabilities и кастомные ограничения.

↑ К оглавлению

6. Проверьте кастомный PHP-код

Разные товары для гостей и авторизованных пользователей иногда создаются буквально несколькими строками PHP.

Код может находиться:

• в functions.php;
• дочерней теме;

• собственном плагине;
• mu-plugins;
• Code Snippets;
• старой доработке предыдущего разработчика.

На сервере можно начать с поиска характерных конструкций:

grep -RIn \
  --exclude-dir=node_modules \
  --exclude-dir=vendor \
  -E 'is_user_logged_in|pre_get_posts|woocommerce_product_query|woocommerce_product_is_visible|catalog_visibility' \
  wp-content/themes \
  wp-content/plugins \
  wp-content/mu-plugins

Не каждое найденное совпадение является ошибкой.

Задача команды — определить, есть ли вообще код, который:

• проверяет авторизацию;
• изменяет product query;
• вмешивается в видимость товара;
• изменяет основной WordPress query.

Например, условие вида:

if ( ! is_user_logged_in() ) {
    // изменить список товаров
}

уже требует проверки.

Если такое поведение было задумано раньше, новый товар мог просто не попасть в нужное условие, категорию или whitelist.

Не удаляйте найденный код сразу на production.

Сначала выясните, зачем он существует, и проверьте изменение на staging или резервной копии.

↑ К оглавлению

7. Проверьте, чем именно выводятся «последние товары»

Фраза «последние товары не показываются гостям» не всегда означает проблему основной страницы магазина.

Новые товары могут выводиться через:

• WooCommerce Product Collection block;
• Gutenberg block;
• shortcode;
• Elementor;
• другой page builder;
• виджет темы;
• собственный PHP-шаблон;
• кастомный запрос.

Поэтому нужно определить источник конкретного блока.

Например, стандартный магазин WooCommerce может работать правильно, а блок «Последние товары» на главной странице — нет.

Проверьте:

/shop/                → новый товар есть?
категория             → новый товар есть?
прямая ссылка         → работает?
главная / блок        → товара нет?

Если первые три пункта работают, проблема уже не в публикации товара.

Она находится в механизме вывода конкретного блока.

Shortcode

Если используется [products], проверьте его параметры:

• category;
• ids;
• skus;
• visibility;
• order;
• orderby;
• limit.

Например, блок может быть ограничен определённой категорией, а новый товар в неё просто не добавлен.

Кастомный PHP-запрос

Если товары выводит собственный PHP-код, проверьте условия запроса.

Для работы с товарами WooCommerce предпочтительнее использовать API самого WooCommerce:

$products = wc_get_products( [
    'limit'   => 10,
    'orderby' => 'date',

    'order'   => 'DESC',
    'status'  => 'publish',
] );

или WC_Product_Query, а не строить сложную логику напрямую вокруг внутренней структуры базы WooCommerce.

На сервере можно быстро проверить, какие опубликованные товары WooCommerce считает последними:

wp eval '
$ids = wc_get_products([
    "limit"   => 10,
    "orderby" => "date",
    "order"   => "DESC",
    "status"  => "publish",
    "return"  => "ids",
]);

print_r($ids);
'

Если ID проблемного товара присутствует здесь, но его нет в конкретном frontend-блоке, значит сам WooCommerce товар видит.

Дальше исследуйте уже:

query блока → фильтры → шаблон → кеш

а не карточку товара.

↑ К оглавлению

8. Сравните обычный каталог и проблемный блок

Это один из самых быстрых способов локализации.

Предположим, новый товар имеет ID 123.

Проверьте:

Прямая карточка товара    → работает
Категория                 → товар есть
/shop/                    → то
вар есть
Блок «Последние товары»   → товара нет

В этом случае нет смысла менять:

• статус товара;
• stock;
• базовые настройки каталога;
• постоянные ссылки.

Проблема практически локализована до блока вывода.

Другой вариант:

Прямая карточка товара    → работает
Категория                 → товара нет
/shop/                    → товара нет

Здесь проверяйте:

• Catalog visibility;
• stock visibility;
• фильтры WooCommerce;
• product lookup data;
• кеш каталога.

И третий вариант:

Администратор → всё работает
Гость → везде старая версия

Здесь первым делом проверяйте HTML-кеш и ограничения по авторизации.

Такой подход намного быстрее случайного отключения плагинов.

↑ К оглавлению

9. Проверьте transients и таблицы поиска WooCommerce

Если настройки товара правильные, кеш HTML исключён, но каталог всё равно ведёт себя странно, можно проверить внутренние данные WooCommerce.

Откройте:

WooCommerce → Status → Tools

Там есть несколько инструментов, полезных именно для диагностики каталога.

WooCommerce transients

WooCommerce хранит часть временных данных в transients.

Если подозреваете устаревшие данные магазина, можно очистить WooCommerce transients и повторить тест.

После очистки обязательно снова проверяйте страницу как гость.

Не делайте вывод только по админке.

Product lookup tables

WooCommerce использует lookup tables, чтобы быстрее получать некоторые данные о товарах.

Если эти данные рассинхронизировались, в инструментах WooCommerce есть регенерация product lookup tables.

Особенно имеет смысл проверить это, если проблема появилась после:

• массового импорта;
• миграции;
• нестандартного обновления товаров;
• собственного скрипта импорта;
• изменений напрямую в базе.

Регенерация большой таблицы на крупном production-магазине может занять время, поэтому не запускайте её без причины в период высокой нагрузки.

Term counts

Если странно ведут себя категории, фильтры или количество товаров, полезен пересчёт term counts.

Но это не первая кнопка, которую нужно нажимать при любой проблеме с товаром.

Сначала докажите, что:

товар опубликован
+
видимость правильная
+
кеш исключён
+
ограничений по ролям нет

и только потом переходите к внутренним индексам.

Не очищайте Customer Sessions «на всякий случай»

В списке инструментов WooCommerce есть очистка клиентских сессий.

Для проблемы отображения новых товаров это обычно не тот инструмент, с которого нужно начинать.

Очистка активных customer sessions может затронуть данные текущих пользовательских сессий и корзин.

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

↑ К оглавлению

10. Проверьте тему и плагины, но только после локализации

Отключение всех плагинов — полезный диагностический метод, но плохой первый шаг на живом магазине.

До него желательно уже знать:

• проблема есть только у гостей или у всех;
• работает ли прямая карточка;
• работает ли /shop/;
• проблема только в одном блоке или во всём каталоге;
• исключён ли page cache.

Если после этого остаётся подозрение на конфликт, проводите проверку на staging.

Рабочая схема:

production → backup → staging

На staging:

1. повторите проблему;
2. временно переключитесь на стандартную тему;
3. проверьте каталог;
4. если проблема осталась — отключите сторонние плагины, оставив WooCommerce;
5. снова проверьте;
6. возвращайте плагины по одному.

Результат интерпретируется просто.

После смены темы товар появился

Проблема, скорее всего, в:

• WooCommerce template override;
• кастомном loop;
• product block темы;
• hook;
• PHP-коде темы.

После отключения конкретного плагина товар появился

Проверяйте:

• настройки этого плагина;
• его фильтры каталога;
• role restrictions;
• кеширование;
• совместимость с текущей версией WooCommerce.

На production-магазине не стоит массово отключать плагины посреди рабочего дня, особенно если через сайт идут реальные заказы.

↑ К оглавлению

11. Проверьте WooCommerce и PHP-логи

Если товар пропадает из-за PHP-ошибки, проблемного шаблона или стороннего кода, полезную информацию можно найти в логах.

Начните с:

WooCommerce → Status → Logs

Проверьте fatal-errors за время, когда загружалась проблемная страница.

На сервере также полезны:

• PHP-FPM log;
• web-server error log;
• системный журнал сервиса PHP.

Например, для Nginx:

tail -f /var/log/nginx/error.log

Для PHP-FPM путь зависит от системы и конфигурации.

При systemd можно посмотреть сервис:

journalctl -u php8.3-fpm --since "10 minutes ago"

Версия PHP в имени сервиса может быть другой.

Теперь:

1. откройте страницу магазина как гость;
2. обновите страницу;
3. посмотрите, появилась ли новая ошибка в журнале.

Ищите не любое старое предупреждение, а событие, которое воспроизводится одновременно с проблемным запросом.

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

↑ К оглавлению

12. Если товар появился после очистки кеша — проблема ещё не решена

Это важный момент.

Допустим:

новый товар не виден гостю
↓
Purge cache
↓
товар появился

Это подтверждает причину, но не устраняет её.

После следующего изменения каталога ситуация может повториться.

Нужно проверить, происходит ли автоматическая инвалидация кеша при:

• публикации товара;
• обновлении товара;
• изменении цены;
• изменении stock status;
• изменении категории.

Нормальная схема выглядит так:

товар изменился
↓
соответствующий кеш инвалидирован
↓
следующий посетитель получает свежую страницу
↓
новая версия кешируется

Плохая схема:

товар изменился
↓
HTML магазина продолжает жить несколько часов
↓
администратор видит origin
↓
гости видят старый cache

В таком случае исправлять нужно политику кеширования или purge, а не WooCommerce.

↑ К оглавлению

13. Если новые товары добавляются импортом

Отдельно проверьте способ создания товара.

Если карточки создаются через:

• CSV;
• XML;
• 1С;
• ERP;
• CRM;
• собственный API;
• cron;
• кастомный PHP-скрипт,

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

Проверьте:

status
catalog visibility
stock status
category
date

Если ручной товар сразу появляется гостям, а импортированный — нет, причина уже значительно сузилась.

Проверяйте импорт.

Особенно подозрительны интеграции, которые изменяют внутренние поля напрямую в базе вместо штатного WooCommerce CRUD API.

После массовых импортов также имеет смысл проверить актуальность product lookup tables и кеша каталога.

↑ К оглавлению

14. Быстрая диагностика через WP-CLI

Если есть SSH и WP-CLI, несколько команд позволяют за пару минут проверить серверную часть проблемы.

Состояние товара

wp eval '
$p = wc_get_product(123);

echo json_encode([
    "status"     => $p ? $p->get_status() : null,
    "visibility" => $p ? $p->get_catalog_visibility() : null,
    "stock"      => $p ? $p->get_stock_status() : null,
], JSON_PRETTY_PRINT);
'

Последние опубликованные товары

wp eval '
print_r(
    wc_get_products([
        "limit"   => 10,
        "orderby" => "date",
        "order"   => "DESC",
        "status"  => "publish",
        "return"  => "ids",
    ])
);
'

Проверка гостевого HTML

curl -sL https://example.com/shop/ \
  | grep -F '/product/new-product/'

Заголовки кеша

curl -sI https://example.com/shop/ \
  | grep -Ei '^(cache-control|age|cf-cache-status|x-cache|x-litespeed-cache|x-varnish):'

Эти проверки отвечают на разные вопросы:

wc_get_product()
→ что WooCommerce знает о товаре

wc_get_products()
→ попадает ли товар в серверную выборку

curl HTML
→ что реально получает гость

cache headers
→ мог ли ответ прийти из кеша

Вместе они намного полезнее, чем случайное переключение настроек.

↑ К оглавлению

15. Короткий алгоритм: что проверять по порядку

Если товары WooCommerce не показываются гостям, проходите диагностику именно сверху вниз.

Шаг 1. Воспроизведите проблему

Сравните:

admin
vs
incognito

на:

карточке
категории
магазине
проблемном блоке

Шаг 2. Проверьте сам товар

Нужны:

Status = Published
Visibility = Public
Catalog visibility = подходящий режим

Шаг 3. Проверьте stock

Убедитесь, что товар не исключается настройкой скрытия отсутствующих товаров.

Шаг 4. Проверьте кеш

Особенно если:

старые товары гостю видны
новые — нет
администратор видит всё

Сравните HTML и cache headers.

Шаг 5. Проверьте правила гостей и ролей

Ищите:

membership
wholesale
B2B
catalog 
mode
product visibility
custom role rules

Шаг 6. Определите источник вывода

Проверьте отдельно:

/shop/
category
shortcode
Product Collection block
page builder
custom PHP

Шаг 7. Проверьте WooCommerce Tools

Только если предыдущие проверки ничего не дали:

transients
product lookup tables

term counts

Шаг 8. Проверьте конфликт

На staging:

theme
↓
plugins
↓
custom code

Шаг 9. Посмотрите логи

Воспроизведите проблему и одновременно смотрите:

WooCommerce fatal-errors
PHP
Nginx / Apache

↑ К оглавлению

Почему администратор видит товар, а гость нет?

Сам факт различия уже является диагностическим признаком.

Авторизованный администратор и обычный посетитель могут получать разные результаты по нескольким причинам:

private product
role-based visibility
logged-in conditions
page cache bypass
CDN cache bypass
membership rules
custom PHP

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

Если WooCommerce возвращает правильный товар, но гостевой HTML старый — проблема в кеше.

Если прямая карточка доступна, но товар не входит в каталог — проверяйте видимость и запрос каталога.

Если товар появляется сразу после авторизации — проверяйте правила ролей и кеш для гостей.

Если проблема существует только в блоке «Последние товары» — исследуйте сам блок, а не весь WooCommerce.

↑ К оглавлению

Главное

Когда товары WooCommerce не показываются гостям, а администратор их видит, сама разница между двумя состояниями помогает найти причину.

Начинайте не с переустановки и не с отключения всего подряд, а с простой цепочки:

↑ К оглавлению

Частые вопросы

Почему новый товар WooCommerce виден администратору, но не покупателям?

Сначала проверьте статус публикации и Catalog visibility. Если они правильные, откройте страницу в режиме инкогнито и проверьте кеш. Когда администратор получает свежую страницу, а гости — старую кешированную копию, новые товары могут быть видны только после авторизации.

Почему последние товары WooCommerce не появляются на главной?

Проверьте, появляются ли они на `/shop/` и в категории. Если там товары есть, проблема находится в блоке на главной: его запросе, shortcode, page builder, фильтрах или кеше.

Может ли Cloudflare скрывать новые товары WooCommerce?

Cloudflare не обязан кешировать HTML магазина при стандартной конфигурации. Но HTML может попадать в edge cache при использовании APO или соответствующих Cache Rules. Если страница для гостя имеет кешированный ответ и после purge появляются новые товары, нужно проверять правила кеширования и инвалидацию.

Нужно ли очищать всю базу или переустанавливать WooCommerce?

Нет. Для этой проблемы это плохая отправная точка. Сначала определите, доступна ли карточка товара гостю, попадает ли товар в каталог и получает ли посетитель свежий HTML. Обычно после этих проверок область поиска значительно сужается.

↑ К оглавлению

Нужна помощь с WooCommerce?

Если после последовательной проверки причина остаётся неясной, можно обратиться за диагностикой WooCommerce. Также полезно сравнить проблему с руководством по неработающей корзине WooCommerce, общей страницей диагностики WooCommerce и проверкой checkout.

Через платформу KWORK ↗Здесь, без регистрации →

↑ К оглавлению