Skip to content

Troubleshooting

webdesign29 edited this page Jun 13, 2026 · 1 revision

Troubleshooting

Dashboard says "Not detected"

In Auto mode the plugin only detects bext from a PHP request, and cache HITs never run PHP. So:

  • Load a URL that misses the cache (e.g. ?cb=123) once — detection fires and sets the sticky flag.
  • Confirm bext sends the BEXT_SERVER FastCGI param (a quick probe: <?php echo $_SERVER['BEXT_SERVER'] ?? 'none';).
  • Or force it: define( 'BEXT_WP_ASSUME_BEHIND_BEXT', true ); (auto) or use Cloud mode.

Under WP-CLI there's no FastCGI param, so wp bext status reflects the sticky flag / mode and bext version may be blank — that's normal.

Purges don't seem to take effect

  • Check the Purge log (Dashboard) — is the URL listed?
  • Test directly: wp bext purge /the/path/ → expect {"purged":1} (or more). If it returns purged:0, that exact key wasn't cached (trailing slash? query string? already expired?).
  • Cloud mode: verify BEXT_PURGE_TOKEN is set on the bext server and matches the plugin's Cloud API token, and that bext was fully restarted (not a ZDT swap) after setting the env.
  • Confirm you're hitting purge-proxy, not the legacy cache-purge port (v0.2.0+ does this automatically).

"Purge on save" doesn't fire

  • Is Purge on save enabled (Settings)? Is the Cache module enabled? Is the site detected as behind bext?
  • Drafts/pending posts aren't purged (they're not publicly cached) — only publish transitions.

Edited a deep src/lib file but nothing changed

Not applicable to bext-wp itself, but on the bext server the route watcher only watches route files — see the bext docs. For the plugin, just re-run the deploy or git pull.

Action Scheduler still self-calling

  • Dashboard → Action Scheduler & cron should say "Async loopback runner: disabled". If not, the Cron module may be disabled, the site not detected, or bext/system_cron_expected returned false (no DISABLE_WP_CRON). Set up the system cron and DISABLE_WP_CRON=true.

A site is 000 / unreachable in smoke tests

Often the directory name ≠ served domain (e.g. a dir Foo.staging.example whose live domain is foo.fr). Smoke-test the real domain. A curl --resolve cert-name mismatch can also yield 000 even though the site is fine — test with the canonical hostname (or -k to bypass cert validation when diagnosing).

Settings show "overridden by constant"

A BEXT_WP_* constant in wp-config.php takes precedence over the matching field. Remove the constant to manage it from the UI.

Still stuck?

Run wp bext doctor, then open an issue on the repository with the output.

Clone this wiki locally