Intégration WordPress

bext exécute réel WordPress — le PHP réel, vos thèmes, vos plugins, WooCommerce — derrière lui. Les requêtes PHP sont envoyées à PHP-FPM via le protocole FastCGI à l'aide de la mascarade compatible nginx de bext ; les actifs statiques sont servis directement à partir du disque ; et toute la surface anonyme se trouve derrière le cache pleine page de bext avec un service périmé, de sorte qu'un visiteur déconnecté obtient du HTML en quelques millisecondes même lorsque l'origine est occupée.

Il n'y a rien à réécrire. Vous conservez le stock WordPress et le stock WooCommerce ; bext remplace la pile nginx + Varnish + page-cache-plugin par un binaire qui parle déjà PHP-FPM, TLS, HTTP/2, HTTP/3 et WAF.

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 termine TLS, exécute le WAF et vérifie le cache pleine page.
2. Un accès au cache pour une requête anonyme est servi depuis la mémoire dans millisecondes — PHP n'est jamais touché.
3. En cas d'échec (ou pour un utilisateur connecté / un panier / un POST), bext transmet la requête à PHP-FPM via FastCGI. WordPress s'affiche comme d'habitude.
4. Fichiers statiques sous wp-content/, wp-includes/, uploads, CSS, JS et les images sont servies directement à partir du disque, jamais via PHP.
5. Lorsque le contenu change, le plugin bext pour WordPress est purgé. exactement les URL concernées à la périphérie — afin que le cache reste long ET frais.

Mise en cache anonyme d'une page entière avec service obsolète#

Le dilemme classique de mise en cache WordPress est « TTL long mais périmé » par rapport à « TTL court mais lent ». bext l’évite. Les réponses anonymes sont mises en cache avec une longue durée de vie et une fenêtre de revalidation obsolète : lorsqu'elles sont fraîches, elles sont servies à partir du cache ; une fois la durée de vie expirée, bext sert instantanément la copie obsolète et la revalide en arrière-plan. Les visiteurs n’attendent jamais un rendu froid. Voir le guide de mise en cache pour la mécanique TTL/SWR et la protection contre la bousculade.

Ce qui n'est jamais mis en cache :

• Utilisateurs connectés (un cookie wordpress_logged_in_* est présent)
• Sessions WooCommerce / paniers non vides (un cookie woocommerce_*)
• wp-admin, wp-login.php, wp-cron.php
• Toute demande paramétrant un cookie de personnalisation

Le plugin sécurise cela en émettant les en-têtes de cache corrects afin que bext sache précisément quelles réponses sont personnalisées et lesquelles sont partagées (voir « En-têtes de cache sécurisés pour la personnalisation » ci-dessous).

bext pour WordPress (le plugin)#

bext-wp est le plugin compagnon qui permet à un WordPress d'installer un citoyen bext de première classe. Il est compatible GPL-2.0 et multisite.

Ce que ça fait#

• Purge lors du changement. Crochets save_post, comment_post, terme et modifications de menu, modifications de stock/prix/commande WooCommerce et sauvegardes du personnalisateur de thème. Sur chacun, il purge uniquement les URL concernées (la publication, ses archives, la page d'accueil, les flux) en bordure. C’est ce qui permet au TTL de rester longtemps sans jamais proposer de contenu obsolète – pas de compromis entre obsolète et lent.
• Apprivoisation du planificateur d'actions . Le planificateur d'actions de WooCommerce peut martelez admin-ajax.php et wp-cron.php dans un DDoS auto-infligé dans un magasin très fréquenté. Le plugin redirige les ticks du planificateur vers un exécuteur raisonnable et à débit limité (éventuellement vers l'exécuteur de tâches bext via le pont SDK) afin que le point de terminaison administrateur AJAX cesse de fondre sous la charge.
• En-têtes de cache sécurisés par la personnalisation. définit cache-control, Les balises de cache vary et bext afin que les pages anonymes soient mises en cache tandis que les réponses connectées/panier/non-portantes sont contournées. Plus besoin de mettre en cache une barre d'administration connectée pour le monde entier.
• Tableau de bord opérateur + tablette de barre d'administration. Un écran de paramètres sous Les outils affichent l'état du cache, le taux de réussite, la dernière purge et le point de terminaison bext détecté. Une petite pilule dans la barre d'administration affiche HIT / MISS / BYPASS pour la page actuelle et propose une "purger cette URL" en un seul clic.
• Multisite. Paramètres au niveau du réseau, plus purge intersites pour un Les changements d'actifs partagés ou de termes partagés distribuent une purge à chaque site du réseau qui y fait référence.
• Pont SDK en option. Lorsqu'il est activé, wp_mail() est acheminé via la capacité de messagerie bext et le travail en arrière-plan (y compris le planificateur d'actions apprivoisé) sont confiés à l'exécuteur de tâches bext au lieu de WP-Cron. Désactivé par défaut ; inscrivez-vous depuis le tableau de bord.

WP-CLI#

Le plugin enregistre une commande wp bext :

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 est le moyen le plus rapide de confirmer la détection bext et l’exactitude de l’en-tête après l’installation.

Installation#

Deux chemins pris en charge :

1. Plugin normal. Installez le zip bext-wp comme n'importe quel autre plugin et activez-le.
2. Plugin indispensable. Le script de déploiement de flotte peut le déposer dans wp-content/mu-plugins/ afin qu'il se charge automatiquement sur chaque site et ne puisse pas être désactivé par un client. Il s'agit du mode recommandé pour les flottes gérées/agences.

Détection#

Le plugin détecte qu'il s'exécute derrière bext via un paramètre FastCGI que bext injecte à chaque requête PHP :

BEXT_SERVER = 1

La mascarade compatible nginx de bext définit automatiquement ce fastcgi_param pour tout PHP-FPM en amont auquel il fait face. Lorsque BEXT_SERVER est présent, le plugin active la purge des bords et active la pilule de la barre d'administration. Lorsqu'il est absent, il reste inerte : le même code peut être expédié en toute sécurité dans un bundle indispensable qui peut également atterrir sur des hôtes non bext.

Mode nuage#

Lorsque WordPress et le dispositif Edge bext ne se trouvent pas sur le même hôte (un dispositif Edge distant ou un niveau de cache distinct), le plug-in communique avec un point de terminaison de purge distant au lieu du socket local. Pointez-le vers le point de terminaison et authentifiez-vous avec un jeton Bearer :

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

En mode cloud, chaque purge est un HTTPS POST authentifié portant le jeton du porteur ; en mode local, il va directement au socket de purge du cache sur l'hôte sans aller-retour.

La suite de plugins Inklura#

Au-delà de bext-wp, la suite Inklura est un ensemble de plugins WordPress ciblés conçus pour fonctionner proprement sur bext. Tous sont GPL-2.0, multisite-aware et auto-mise à jour (voir « Mises à jour automatiques »).

Chaque plugin fonctionne de manière autonome, mais ils partagent le pont SDK bext : les formulaires et le courrier sont envoyés via le logiciel de messagerie bext, Analytics respecte le cache périphérique (les événements sont collectés côté client afin que les pages mises en cache restent mises en cache) et les sauvegardes peuvent être transférées vers l'exécuteur de tâches.

Mises à jour automatiques#

La suite propose son propre canal de mise à jour plutôt que de s'appuyer sur le référentiel wordpress.org. Chaque plugin interroge un manifeste :

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

Le manifeste répertorie la dernière version et une URL de téléchargement pour chaque plugin. Les packages de mise à jour sont des actifs de version GitHub — donc une version balisée sur le dépôt source est la source unique de vérité, et le flux normal de « mise à jour disponible » de WordPress l'installe. Les administrateurs de réseau multisite reçoivent un avis de mise à jour qui s'applique à l'ensemble du réseau.

L'assembler#

Un site WordPress géré typique sur bext ressemble à ceci :

1. WordPress + WooCommerce sur PHP-FPM, servis via bext nginx -compat mascarade (FastCGI), actifs statiques directement à partir du disque.
2. bext-wp comme plugin incontournable (déployé par le script de flotte), détecté via BEXT_SERVER, purgeant à chaque changement de contenu.
3. La suite Inklura pour le référencement, les formulaires, le courrier, les analyses et les sauvegardes.
4. Trafic anonyme servi depuis le cache périphérique en millisecondes ; le trafic de connexion/de panier est automatiquement contourné.
5. Plugins se mettant à jour automatiquement à partir du manifeste Inklura.

Le résultat : WordPress qui se comporte comme un site statique pour les 95 % du trafic anonyme, tout en restant entièrement dynamique pour tous ceux qui sont connectés ou qui achètent, sans contenu obsolète, car le Edge purge dès que quelque chose change.

En rapport#

• PHP et PHP-FPM ( nginx -compat) — Envoi FastCGI et PHP intégré
• Mise en cache — TTL, périmé pendant la revalidation, garde de bousculade
• Mode mascarade — fonctionnant en tant que module d'insertion nginx
• API de purge du cache — le point de terminaison appelé par le plugin
• Capacité de messagerie — à quoi le pont SDK connecte wp_mail()

Links#

• Source du plugin : github.com/webdesign29/ bext -wp
• Vitrine de la suite : wp-plugins.inklura.fr
• Wiki et guides : github.com/webdesign29/ bext -wp/wiki