Back to Community

Troubleshooting Breeze Cache Issues for Logged-in Users and Dynamic Content

21 threads Sep 16, 2025 PluginBreeze – wordpress cache plugin

Content

Why Your Cached Pages Aren't Updating for Logged-in Users

Many WordPress site administrators choose the Breeze – WordPress Cache Plugin for its performance benefits. However, a common point of confusion arises when dealing with dynamic content, user-specific pages, and cache management for non-admin users. This guide explains the core behaviors of the Breeze plugin and provides actionable solutions for these frequent scenarios.

Common Symptoms and Root Causes

Users often report issues such as:

  • Shop Managers or other user roles cannot see a "Purge Cache" button.
  • Content updates made by logged-in users are not immediately visible.
  • Logout pages or user-specific data (like avatars or menus) appear to be stuck in a cached state.
  • Password changes made directly in the database do not take effect until a full cache purge.

These problems stem from a few key design aspects of the Breeze plugin:

  1. Default Cache Behavior: By default, Breeze does not cache pages for logged-in users. This is a standard practice to prevent serving personalized content to the wrong person.
  2. Role-Based Cache Purge Access: Historically, the ability to purge the cache was restricted to users with Administrator and Editor roles. This meant Shop Managers or other custom roles could not easily clear the cache to see their changes.
  3. Aggressive Browser Caching: Breeze can set long max-age headers (e.g., 30 days) for certain assets, which may cause browsers to serve old content from their local cache.
  4. Per-User vs. Per-Role Caching: When the "Cache Logged-in Users" feature is enabled for a role, it creates a unique cache file for each individual user. This can lead to a massive number of files on large membership sites but ensures user-specific data is correct.

Actionable Solutions and Workarounds

1. Granting Cache Purge Permissions to Shop Managers

Problem: A Shop Manager needs to clear cache to see updates but lacks the button.

Solution: This feature has been addressed. As of Breeze version 2.1.12, the 'Purge All Cache' option is now available for the Shop Manager role. Simply updating the plugin to the latest version should resolve this issue.

2. Handling Dynamic Content and Immediate Updates

Problem: You need changes to be visible immediately after updating a post or page.

Solution: The Breeze – WordPress Cache Plugin team states that the plugin is designed to automatically purge all static cache data whenever a post or page is created or edited. For dynamic content that relies on third-party plugins or APIs, a full immediate purge might not always be triggered. Manually purging the cache after making critical updates is the most reliable method to ensure changes are visible.

3. Configuring Cache Exclusions for Specific Pages

Problem: Pages like logout URLs or membership pages are being cached, causing issues.

Solution: Use the "Never Cache the following pages" option in Breeze's settings. For a logout link, you would typically exclude a path like /wp-login.php?action=logout or a specific page created by a membership plugin (e.g., /my-account/logout). Testing with different exclusion patterns is often necessary.

4. Managing Cache for Logged-in Users

Problem: You want to cache pages for logged-in users to improve performance but avoid creating a cache file for every single user.

Solution: Currently, the "Cache Logged-in Users" feature operates on a per-user basis for accuracy. If your site's pages for a specific role contain no personal data (e.g., a shared dashboard), caching on a per-role basis would be more efficient. This is a known feature request within the community, but as of now, per-user caching is the standard implementation to maintain security and data integrity.

5. Dealing with Browser Cache (max-age headers)

Problem: Browser caching is too aggressive, showing old content even after server cache is cleared.

Solution: Recent versions of Breeze have updated their default expiration headers for HTML pages to max-age=0, which should help. If you are on an older version or need to adjust other asset timings, you may need to manually modify the cache expiration rules in the .htaccess file or consult your hosting provider if they manage these settings.

When to Seek Further Help

If you have followed these steps and continue to experience issues, particularly in complex setups like Multisite networks or with specific plugins, the problem may require more advanced debugging. Common next steps include:

  • Testing with all other plugins disabled to rule out a conflict.
  • Checking for any server-level caching (e.g., Varnish, Nginx FastCGI) that might need to be purged separately.
  • Ensuring your WordPress and Breeze plugin are updated to their latest versions to incorporate all recent fixes.

Related Support Threads Support