Connection Modes

Connection Modes

bext-wp talks to bext over HTTP. Mode decides where and how.

Mode	Transport	Auth	Use when
Auto (default)	http://127.0.0.1:80 (bext main listener, loopback)	none (loopback-gated)	bext runs on the same server as PHP
Cloud	configured remote URL	Authorization: Bearer <token>	WordPress runs off-box, behind a remote bext / bext cloud edge
Off	—	—	temporarily disable the integration

Set the mode in Bext → Settings, or define( 'BEXT_WP_MODE', 'auto' );.

Auto

The common case: bext serves the site and PHP on the same machine.

• Cache purge → POST http://127.0.0.1/__bext/cache/purge-proxy
• SDK → POST http://127.0.0.1/__bext/sdk/* with X-Bext-App-Id (loopback bypass)
• No credentials, no file-system reads (open_basedir-safe).

Detection (auto only): the plugin only acts when it's actually behind bext. It detects via:

1. the BEXT_SERVER FastCGI param bext sets on every PHP request,
2. the x-bext-cache-refresh header (bext's background-refresh self-request),
3. a sticky one-time flag (bext_wp_detected), or
4. BEXT_WP_ASSUME_BEHIND_BEXT.

Cache HITs never reach PHP, so detection fires on the first cache-miss/PHP request. See Troubleshooting if the dashboard says "Not detected".

Cloud

For sites where the PHP process is not on the bext host (managed WordPress behind a bext cloud edge, or any split). Calls go to the configured endpoint with a bearer token. Configuring an endpoint is itself the "behind bext" signal (no FastCGI param needed).

Full setup: Bext Cloud.

Off

Disables all integration behavior (is_behind_bext() returns false; feature modules don't act). The Settings and Dashboard pages remain so you can turn it back on.