Bext for WordPress
WordPress qui coopère avec le cache, au lieu de le subir : purge chirurgicale à chaque modification, taming d'Action Scheduler, en-têtes sûrs, tableau de bord opérateur et pont SDK — pour les sites servis par bext.
Fini le choix entre « rapide » et « à jour »
TTL long : rapide mais périmé. TTL court : frais, mais chaque premier visiteur paie un rendu PHP complet (~4,4 s mesurées sur un vrai site WooCommerce).
Cache classique
- TTL long → contenu périmé après chaque modification
- TTL court → rendu PHP complet à chaque cycle
- Action Scheduler s'auto-appelle (5–21 s) et sature PHP-FPM
- Risque de mettre en cache une page connectée
Avec Bext
- TTL long ET frais : WordPress purge les bonnes URL à l'édition
- Purge ciblée et non bloquante (une seule requête)
- Runner Action Scheduler maîtrisé → le cron système draine la file
- Connecté / panier / commentaire → jamais mis en cache anonyme
Huit modules, activables un par un
Chacun se désactive d'un cran (constante, réglage ou filtre) et ne fait rien si le site n'est pas servi par bext.
Cache coopératif
À chaque publication, bext-wp calcule les URL impactées (permalien, accueil, archives, flux, sitemap) et les purge en une seule requête non bloquante. Le cache reste long, le contenu reste frais.
Taming d'Action Scheduler
Désactive le runner loopback admin-ajax (mesuré à 5–21 s) et laisse le cron système vider la file. Fini les auto-requêtes qui saturent PHP-FPM.
En-têtes sûrs
Les réponses connectées / panier / commentaire reçoivent Cache-Control: private, no-store — jamais mises en cache pour les visiteurs anonymes.
Tableau de bord
Une page « Bext » dans l'admin + une pastille dans la barre : statut, journal de purge, file Action Scheduler, contrôles de santé, accessibilité du serveur.
Réglages & bext cloud
Tout se configure depuis l'admin (mode local ou cloud, endpoint, jeton, modules) — sans toucher à wp-config. Mode cloud pour WordPress derrière une edge bext distante.
Pont SDK
Optionnel : wp_mail via l'envoi e-mail géré de bext et des jobs d'arrière-plan sur une file bext. Tout échoue en sécurité (repli vers WordPress).
Multisite
Réglages réseau (défauts + verrouillage), tableau de bord multi-sites avec purge par site ou globale, et clés de cache correctes en sous-répertoire.
WP-CLI
wp bext status · wp bext purge [chemin] · wp bext doctor — pour scripter purges et diagnostics depuis le terminal ou la CI.
Deux façons de connecter
- Auto (local) — bext sert WordPress sur la même machine, via le loopback
127.0.0.1:80: aucune clé, compatible open_basedir. Détection par le paramètre FastCGIBEXT_SERVER. - Cloud (distant) — WordPress dialogue avec une edge bext distante via un jeton porteur, configuré dans
Bext → Réglages.
WP-CLI
wp bext purge [chemin] # purge tout ou une URL
wp bext doctor # contrôles de santé
Installation
git clone github.com/webdesign29/bext-wp.git
# must-use sur toute une flotte (copie par site)
sudo bin/deploy-fleet.sh --site=exemple.com
- Installez — En extension classique, ou en must-use sur toute une flotte via bin/deploy-fleet.sh (copie par site, compatible open_basedir).
- Détection auto — bext-wp détecte qu'il est servi par bext (paramètre FastCGI BEXT_SERVER) et n'agit que dans ce cas. Rien à brancher.
- Configurez — Choisissez le mode (local / cloud) et activez les modules depuis Bext → Réglages. Ou verrouillez tout via des constantes wp-config.
- Profitez — Modifiez un article : les bonnes URL sont purgées en arrière-plan. Le cache reste long, votre site reste frais et rapide.