Troubleshooting

Troubleshooting

Nothing is being cached

Work down this list; each step rules out the one above.

1. wp gt-performance doctor — is the drop-in owned and WP_CACHE enabled? If the drop-in is missing, install it. If it is conflict, another caching plugin owns advanced-cache.php; disable that plugin first.
2. Are you logged in? wordpress_logged_in_ is a bypass cookie. Test in a private window.
3. wp gt-performance cache explain --page-url=… — it will name the deciding rule.
4. Check for an unknown query parameter. Any parameter not on the ignored list bypasses by design. Add legitimate ones to ignored query parameters.
5. Check the response. A page that sets any cookie, returns anything but 200, or is not text/html is never stored. X-GT-Cache: DYNAMIC with Debug on tells you which.

Cache works logged out but the site looks stale to me

Expected. Logged-in requests bypass. If visitors see stale content, purge and check Age.

A page updated but visitors still see the old version

1. Purge the origin: wp gt-performance cache purge --page-url=…
2. Purge the edge: wp gt-performance cloudflare purge --page-url=…
3. Re-check with a cache-busting query parameter, not the bare URL — the bare URL may be answered by an edge copy.

If a served copy survives repeated purges with a growing Age, the copy is held by a layer your token does not address — typically a host-managed Cloudflare. Purge from the host's dashboard, or wait for s-maxage to expire.

Blank page or "critical error" after updating

If the site was on 1.0.0 or earlier, its old generated drop-in loads a runtime file list that no longer matches the plugin. Fix it at the filesystem level — the site cannot run WP-CLI in this state, because WP-CLI boots WordPress and hits the same failure:

rm wp-content/advanced-cache.php

The site returns immediately (no drop-in simply means no page cache). Then sign in to wp-admin once and GT Performance republishes a correct drop-in.

The standalone repair script does this and the rest of the migration: https://gist.github.com/wpgaurav/03d61d313df00b4127db92393ed74681

See Upgrading.

Buttons in the admin do nothing / return a blank page

Fixed in 1.0.2 and 1.0.3. If you are on 1.0.1, update.

Cart or account shows the wrong visitor's data

Stop and bypass the affected pages immediately under Exceptions, then run wp gt-performance safety. Report it — this is the failure class the whole design exists to prevent.

Layout breaks after enabling CSS optimization

1. Set rollout to 0 to stop serving optimized CSS while you investigate.
2. Reproduce with ?gtperf_css_preview=<nonce> as an administrator — it renders through the pipeline without caching anything.
3. Add the missing selector to the safelist, or exclude the whole stylesheet.
4. If the missing styles only appear after JavaScript runs, use Training Mode.

Something breaks after enabling JavaScript delay

Delay is the highest-risk switch. Turn it off first, confirm recovery, then re-enable with the offending script excluded. Do not debug delay and defer at the same time.

Redis object cache will not install

wp gt-performance doctor reports the Redis drop-in state. Installation runs a connection test first and refuses rather than installing a drop-in that cannot connect. Check host, port, credentials and TLS under Integrations, then Test and install Redis.

If another plugin owns object-cache.php, GT Performance will not overwrite it.

Constants in wp-config.php are being ignored

They must use the GTPERF_ prefix. Sites installed before 1.0.1 used GTP_, which is no longer read. See Constants Reference.

Cache directory is not writable

wp-content/cache/gt-performance must be writable by the web server user. doctor reports this. On a read-only filesystem the plugin degrades to no caching rather than erroring.

Related

Diagnostics · Upgrading · WP-CLI