WordPress Integration

bext runs real WordPress — the actual PHP, your themes, your plugins, WooCommerce — behind its edge. PHP requests are dispatched to PHP-FPM over the FastCGI protocol using bext's nginx-compat masquerade; static assets are served straight from disk; and the whole anonymous surface sits behind bext's full-page cache with serve-stale, so a logged-out visitor gets HTML in milliseconds even when the origin is busy.

There is nothing to rewrite. You keep stock WordPress and stock WooCommerce; bext replaces the nginx + Varnish + page-cache-plugin stack with one binary that already speaks PHP-FPM, TLS, HTTP/2, HTTP/3, and the WAF.

Tip

This page is about hosting a full WordPress install on bext. If you only want bext's embedded PHP micro-framework (no WordPress), see the PHP runtime reference.

Architecture

client ──TLS──▶ bext edge ──FastCGI──▶ PHP-FPM ──▶ WordPress
                │                          │
                │  full-page cache         │  WooCommerce
                │  serve-stale (SWR)       │  themes / plugins
                │  serves wp-content/**     │
                │  WAF, HTTP/2, HTTP/3     │
                └── purge-on-change ◀───────┘  (Bext for WordPress)
  1. bext terminates TLS, runs the WAF, and checks the full-page cache.
  2. A cache hit for an anonymous request is served from memory in milliseconds — PHP is never touched.
  3. On a miss (or for a logged-in user / a cart / a POST), bext forwards the request to PHP-FPM over FastCGI. WordPress renders as usual.
  4. Static files under wp-content/, wp-includes/, uploads, CSS, JS, and images are served directly from disk, never through PHP.
  5. When content changes, the Bext for WordPress plugin purges exactly the affected URLs at the edge — so the cache stays long AND fresh.

Anonymous full-page caching with serve-stale

The classic WordPress caching dilemma is "long TTL but stale" versus "short TTL but slow". bext sidesteps it. Anonymous responses are cached with a long TTL plus a stale-while-revalidate window: while fresh they're served from cache; once the TTL lapses, bext serves the stale copy instantly and revalidates in the background. Visitors never wait on a cold render. See the caching guide for the TTL / SWR mechanics and the stampede guard.

What is never cached:

  • Logged-in users (a wordpress_logged_in_* cookie is present)
  • WooCommerce sessions / non-empty carts (a woocommerce_* cookie)
  • wp-admin, wp-login.php, wp-cron.php
  • Any request that sets a personalization cookie

The plugin makes this safe by emitting the correct cache headers so bext knows precisely which responses are personalized and which are shared (see "personalization-safe cache headers" below).

Bext for WordPress (the plugin)

bext-wp is the companion plugin that makes a WordPress install a first-class bext citizen. It is GPL-2.0 and multisite-aware.

What it does

  • Purge-on-change. Hooks save_post, comment_post, term and menu edits, WooCommerce stock / price / order changes, and theme customizer saves. On each, it purges only the affected URLs (the post, its archives, the home page, feeds) at the edge. This is what lets the TTL stay long without ever serving stale content — no stale-vs-slow tradeoff.
  • Action Scheduler taming. WooCommerce's Action Scheduler can hammer admin-ajax.php and wp-cron.php into a self-inflicted DDoS on a busy store. The plugin reroutes scheduler ticks to a sane, rate-limited runner (optionally to the bext jobs runner via the SDK bridge) so the admin AJAX endpoint stops melting under load.
  • Personalization-safe cache headers. Sets cache-control, vary, and bext cache tags so anonymous pages are cached while logged-in / cart / nonce-bearing responses are bypassed. No more caching a logged-in admin bar for the whole world.
  • Operator dashboard + admin-bar pill. A settings screen under Tools shows cache status, hit ratio, last purge, and the detected bext endpoint. A small pill in the admin bar shows HIT / MISS / BYPASS for the current page and offers a one-click "purge this URL".
  • Multisite. Network-level settings, plus cross-site purge so a shared-asset or shared-term change fans out a purge to every site in the network that references it.
  • Optional SDK bridge. When enabled, wp_mail() is routed through the bext mailer capability, and background work (including the tamed Action Scheduler) is handed to the bext jobs runner instead of WP-Cron. Off by default; opt in from the dashboard.

WP-CLI

The plugin registers a wp bext command:

wp bext status     # endpoint, mode (fastcgi|cloud), cache hit ratio
wp bext purge      # purge a URL, a tag, or the whole site
wp bext doctor     # diagnose detection, headers, FPM param, token
wp bext flush      # flush the entire edge cache for this site

wp bext doctor is the fastest way to confirm bext detection and header correctness after install.

Installation

Two supported paths:

  1. Normal plugin. Install the bext-wp zip like any other plugin and activate it.
  2. Must-use plugin. The fleet deploy script can drop it into wp-content/mu-plugins/ so it loads on every site automatically and can't be deactivated by a client. This is the recommended mode for managed / agency fleets.

Detection

The plugin detects that it's running behind bext via a FastCGI parameter that bext injects on every PHP request:

BEXT_SERVER = 1

bext's nginx-compat masquerade sets this fastcgi_param automatically for any PHP-FPM upstream it fronts. When BEXT_SERVER is present the plugin enables edge-purge and switches the admin-bar pill on. When absent, it stays inert — the same code is safe to ship in a must-use bundle that may also land on non-bext hosts.

Cloud mode

When WordPress and the bext edge are not on the same host (a remote edge, or a separate cache tier), the plugin talks to a remote purge endpoint instead of the local socket. Point it at the endpoint and authenticate with a bearer token:

BEXT_PURGE_ENDPOINT = https://edge.example.com/__bext/cache/purge
BEXT_PURGE_TOKEN    = <bearer-token>

In cloud mode every purge is an authenticated HTTPS POST carrying the bearer token; in local mode it goes straight to the on-host cache-purge socket with no round trip.

The Inklura plugin suite

Beyond bext-wp, the Inklura suite is a set of focused WordPress plugins designed to run cleanly on bext. All are GPL-2.0, multisite-aware, and self-updating (see "Auto-updates").

Plugin Purpose
Inklura SEO Titles, meta, sitemaps, schema, redirects — without the bloat
Inklura Forms Form builder with spam filtering and the bext mailer bridge
Inklura Mail Transactional / newsletter email through the bext mailer
Inklura Analytics Privacy-first, cookieless page analytics
Inklura Backups Scheduled DB + uploads backups to object storage

Each plugin works standalone, but they share the bext SDK bridge: Forms and Mail send through the bext mailer, Analytics respects the edge cache (events are collected client-side so cached pages stay cacheable), and Backups can offload to the jobs runner.

Auto-updates

The suite ships its own update channel rather than relying on the wordpress.org repository. Each plugin polls a manifest:

https://wp-plugins.inklura.fr/api/update

The manifest lists the latest version and a download URL for each plugin. Update packages are GitHub release assets — so a tagged release on the source repo is the single source of truth, and WordPress's normal "update available" flow installs it. Multisite network admins get one update notice that applies network-wide.

Putting it together

A typical managed WordPress site on bext looks like this:

  1. WordPress + WooCommerce on PHP-FPM, served via bext nginx-compat masquerade (FastCGI), static assets straight from disk.
  2. bext-wp as a must-use plugin (deployed by the fleet script), detected via BEXT_SERVER, purging on every content change.
  3. The Inklura suite for SEO, forms, mail, analytics, and backups.
  4. Anonymous traffic served from the edge cache in milliseconds; logged-in / cart traffic bypassed automatically.
  5. Plugins self-updating from the Inklura manifest.

The result: WordPress that behaves like a static site for the 95% of traffic that is anonymous, while staying fully dynamic for everyone who's logged in or shopping — with no stale content, because the edge purges the moment anything changes.

Related

Links