Сессии WooCommerce и кэш: почему пропадает корзина и смешиваются данные покупателей

Корзина WooCommerce — персональное состояние. Если относиться к ней как к обычной публичной HTML-странице, после подключения CDN или агрессивного page cache появляются знакомые симптомы: товар исчезает после перехода, счётчик корзины показывает старое значение, checkout видит другую сумму или Store API возвращает состояние не той сессии, которую ожидает frontend.

Чтобы диагностировать такие ошибки, нужно разделить три слоя: customer session WooCommerce, клиентские cookies/tokens и серверное кэширование. Простая очистка кэша иногда временно скрывает проблему, но не исправляет архитектуру.

Как WooCommerce связывает корзину с покупателем

Официальная документация Store API прямо указывает, что данные API отражают текущего пользователя, а customer sessions в WooCommerce являются cookie-based. Это принципиальное отличие от административного REST API с Consumer Key/Secret.

Store API предназначен для клиентских сценариев: каталог, корзина, shipping rates и checkout. Он не даёт произвольный доступ к чужим заказам или настройкам магазина. Подробнее различия разобраны в статье Store API vs REST API.

Почему публичный кэш опасен для корзины

Full-page cache эффективен для одинаковых страниц каталога, но персонализированный ответ нельзя бездумно сохранять и отдавать всем. Если cache key не учитывает состояние пользователя, первый ответ может стать шаблоном для следующих запросов.

Особенно внимательно нужно относиться к cart, checkout, account и API endpoints, которые возвращают текущее состояние корзины. На этих маршрутах производительность важна, но корректность и изоляция данных важнее.

Cart API: Nonce Token и Cart Token

Документация Cart API указывает, что POST endpoints корзины требуют Nonce Token или Cart Token. После операции API возвращает обновлённое полное состояние корзины.

Nonce подтверждает происхождение и намерение запроса. WooCommerce также поддерживает Cart Token для работы с корзиной. В checkout endpoints также требуется Nonce Token или Cart Token.

Нельзя отключать nonce validation в production ради упрощения frontend. Официальная документация допускает соответствующий filter только для development-среды, где безопасность не важна.

Симптом: товар добавляется и сразу исчезает

Проверьте цепочку последовательно:

1. Ответ add-to-cart действительно успешный.
2. Browser сохраняет session cookie и отправляет её на следующих запросах.
3. Domain, path, Secure и SameSite не мешают cookie.
4. CDN не кэширует персональный cart response.
5. Frontend не создаёт новую независимую сессию при каждом запросе.
6. Нет конфликтов между www/non-www, HTTP/HTTPS или разными поддоменами.

Если frontend и WordPress работают на разных origins, отдельно проверяйте CORS и credentials. Запрос может быть технически успешным, но без нужных credentials браузер не сохранит или не отправит состояние так, как ожидает приложение.

Симптом: мини-корзина показывает старое количество

Здесь проблема может быть уже не в самой сессии, а в frontend cache. Сервер знает актуальную корзину, но интерфейс продолжает показывать закэшированный фрагмент или старый state.

Сравните три источника: фактический ответ Cart API, HTML/JS состояние интерфейса и checkout. Если API возвращает правильные items, а badge в header нет — искать нужно в клиентском обновлении компонента, а не в базе заказов.

CDN и Cache Everything

Правило уровня CDN «cache everything» опасно применять ко всему WordPress без исключений. Для WooCommerce обычно исключают как минимум cart, checkout, my-account и персональные API routes. Конкретные пути зависят от архитектуры сайта, языка, permalink structure и checkout blocks.

Также проверяйте query strings и cookies, по которым CDN делает bypass. Слишком широкое правило bypass уничтожит пользу кэша, а слишком узкое создаст риск персонализированных ответов.

Redis Object Cache — другая задача

Object cache хранит результаты обращений к объектам и базе, а full-page cache хранит готовый ответ страницы. Поэтому наличие Redis не означает, что cart/checkout можно безопасно кэшировать на edge.

Для WooCommerce object cache может заметно разгрузить backend, но его нужно настраивать отдельно. Практический материал: Redis Object Cache для WooCommerce.

Store API и headless frontend

В headless-проекте ответственность за состояние корзины частично переходит к frontend. Нужно сохранять и обновлять токены так, как требует API, корректно передавать credentials и не считать любой JSON-ответ публично кэшируемым.

Store API является unauthenticated в смысле отсутствия Consumer Key/Secret для публичных customer-facing endpoints, но это не означает отсутствие контекста пользователя. Документация подчёркивает cookie-based sessions и требования nonce для write operations.

Что проверить в Checkout Blocks

Современный block checkout активно использует Store API. Если после оптимизации JavaScript, CDN rules или security middleware оформление заказа начало терять state, сравните поведение до и после оптимизации и проверьте сетевые запросы /wp-json/wc/store/v1/.

429, 403 и stale cached responses требуют разной диагностики. Для защиты от ботов у WooCommerce есть отдельные механизмы rate limiting; их настройка разобрана в материале про rate limiting Store API и Checkout.

Безопасный чек-лист кэширования WooCommerce

• Cart, checkout и account не попадают под общий page cache.
• Store API cart/checkout не кэшируются как публичные ответы.
• Cookies WooCommerce доходят до browser и обратно.
• HTTPS и domain redirects не создают новую сессию.
• Nonce/Cart Token обновляются по правилам API.
• CDN cache rules проверены на анонимном и авторизованном пользователе.
• Мини-корзина сверена с фактическим Cart API response.
• После изменений выполнен тест в двух независимых браузерных сессиях.

Как проверить, что данные покупателей не смешиваются

Откройте две независимые сессии браузера, лучше в разных профилях. В первой добавьте товар A, во второй — товар B. Затем сравните cart endpoints, mini-cart и checkout. Ни один слой не должен показывать состояние соседней сессии.

Такой тест полезнее одиночной проверки в одном incognito window: он сразу выявляет cache key, который не учитывает персональный контекст.

Когда нужна диагностика на сервере

Если cookies выглядят корректно, но корзина всё равно теряется, проверьте PHP session/customer session storage, object cache, database writes, ошибки WooCommerce, reverse proxy и плагины оптимизации. Важно фиксировать один конкретный сценарий и request chain, а не очищать все кэши одновременно.

A.S Groups выполняет диагностику WooCommerce, Store API, checkout и серверного кэша. Описать симптом и текущую схему CDN можно через контакты.