Bext for WordPress

Bext for WordPress is for WordPress sites served by bext. On every change, the plugin purges the cache of the affected pages only: the cache can stay long without serving stale pages.

Installation guide Source code

GPL-2.0 · PHP 7.4+ · WordPress 5.8+ · Multisite · WooCommerce · bext cloud · WP-CLI

wp-admin › Bext · purge log HIT 18 ms

Long cache or fresh pages

Usually you have to choose. On the WooCommerce shop where we measured it, a page generated without cache took about 4.4 seconds.

Without the plugin

With a long cache, a change takes a while to show up.
With a short cache, the first visitor after each expiry waits for the page to be fully generated.
Action Scheduler sends requests to the site itself, which last 5 to 21 seconds and tie up PHP.
An account or cart page may end up cached.

With the plugin

The cache stays long and the pages a change affects are purged straight away.
The purge is sent in a single request, without slowing down the save.
Action Scheduler tasks run through the server's cron.
Account, cart and comment pages are never cached.

The modules

Eight modules, each switched on separately. None of them acts if the site is not served by bext.

Targeted purge: On every publish, the plugin works out the affected pages (the post, the home page, archives, feeds, the sitemap) and purges their cache in a single request, without slowing down the save.
Action Scheduler: WooCommerce background tasks run through the server's cron instead of the requests WordPress sends to itself (measured at 5 to 21 seconds).
Personal pages: Account, cart and comment pages are sent with headers that forbid caching them.
Dashboard: A Bext page is added to the admin, with the connection status, the purge log, the Action Scheduler queue and health checks.
Settings: Local or cloud mode, address, token and modules are set in the admin, or locked with constants in wp-config.
SDK bridge: Optionally, e-mails and background tasks can go through bext services. If that fails, WordPress takes over.
Multisite: Default settings apply to the whole network, purges run per site or globally, and cache addresses stay correct for sites in a subdirectory.
WP-CLI: The wp bext status, wp bext purge and wp bext doctor commands let you script purges and diagnostics.

Installation

The step-by-step guide covers each step with screenshots.

Getting started

Install. Install it like any plugin, or as a must-use plugin across several sites with the bin/deploy-fleet.sh script.
Detection. The plugin checks that it is served by bext (FastCGI parameter BEXT_SERVER). Otherwise it does nothing.
Settings. Choose local or cloud mode and the modules in the Bext › Settings menu, or set them with constants.
First purge. Edit a post: the affected pages are purged in the background, the rest of the cache is kept.

# regular plugin, in wp-content/plugins/
git clone github.com/webdesign29/bext-wp.git
# must-use across several sites
sudo bin/deploy-fleet.sh --site=example.com

Connecting to bext

Local. The bext server serves WordPress on the same machine. The plugin detects it through the FastCGI parameter BEXT_SERVER and goes through 127.0.0.1, with no key to enter.
Cloud. WordPress runs behind a remote bext server. The address and token are entered in the Bext › Settings menu.

WP-CLI

wp bext status # status
wp bext purge [path] # whole site or one URL
wp bext doctor # health checks

Free, under the GPL-2.0 licence.

The code, the tests (PHP 7.4 to PHP 8.3) and the documentation are on GitHub.

Source code Documentation