Contexte : en début mai 2026, on s'est mis à tester Alesta AI directement sur un environnement staging SiteGround via SSH, en activant systématiquement tous les modules. On pensait livrer une v1.3.0 stable. On a fini par sortir 6 versions en deux semaines (1.3.1 → 1.3.6). Voici ce qu'on a trouvé.

Bug n°1 — minify_html() tronque les pages à 27 %

Symptôme : sur les pages WooCommerce avec plus de 200 produits, la page s'arrêtait au milieu d'un <div>. Le source HTML reçu par le navigateur faisait 27 % de la taille attendue.

Cause : notre regex de minification utilisait [\s\S]*? pour matcher non-greedy à travers les balises <script>, <style>, <pre>. Sur des documents de plus de 800 Ko, PHP atteignait pcre.backtrack_limit (défaut 1M), preg_replace_callback() renvoyait null silencieusement, et notre code prenait null comme le résultat minifié.

Fix : nouveau pattern '#<(script|style|pre|textarea)\b[^>]*+>.*?</\1>#is' avec quantifieur possessif *+ qui empêche le backtracking. Ajout d'une élévation temporaire de pcre.backtrack_limit et pcre.recursion_limit à 10M. Ajout d'un check preg_last_error() qui logue et bypass la minif si erreur. Sanity check final : si la sortie fait moins de 50 % de l'entrée, on garde l'entrée.

Bug n°2 — Fatal alesta_ai_get_home_path() undefined

Symptôme : activation du module Minify sur la version Premium => site complètement down, écran blanc, log d'erreur PHP fatal.

Cause : on a refactoré le module Minify depuis la version Free d'Alesta vers la version Pro. La version Free déclarait une fonction utilitaire alesta_ai_get_home_path(). La version Pro… non. Copy-paste fonctionnel en Free, fatal en Pro. Classique régression cross-codebase.

Fix : defensive check avec function_exists('alesta_ai_get_home_path') + fallback sur trailingslashit(ABSPATH). Et surtout : ajout d'un test CI qui charge le plugin Pro dans un WordPress vanille pour catcher ce genre de référence morte.

Bug n°3 — Mixed Content cassait l'éditeur Elementor

Symptôme : impossible d'éditer une page dans Elementor avec Alesta AI v1.3.0 actif. "There has been a critical error on this website".

Cause : on figeait l'URL du dossier cache avec une constante CACHE_URL au moment de l'init du plugin. Sur SiteGround (et tout proxy SSL terminant TLS au niveau load balancer), WP_CONTENT_URL était évalué avant que WordPress lise X-Forwarded-Proto, donc en HTTP. Les feuilles CSS minifiées étaient ensuite servies en HTTP sur une page HTTPS => bloquées par le navigateur.

Fix : nouvelle méthode dynamique cache_url() qui appelle set_url_scheme() avec is_ssl() à chaque utilisation. Plus de constante figée. Détail complet dans l'article dédié.

Bug n°4 — WWW switch sans Search & Replace

Symptôme : les utilisateurs qui activaient l'option "Forcer www" du module .htaccess voyaient leur site continuer à fonctionner côté visiteur, mais des liens internes restaient en https://exemple.fr sans le www dans les widgets Elementor, les sliders, les images de hero.

Cause : le module ne touchait qu'au .htaccess, pas à la BDD. Les URLs sérialisées dans postmeta restaient à l'ancienne valeur. Une redirection 301 corrigeait à la volée pour les visiteurs, mais polluait le SEO et cassait certains AJAX cross-origin.

Fix : codage du module Search & Replace (détail ici) et chaînage automatique avec le module WWW. Activer le WWW lance désormais en transaction : (1) dry-run search-replace, (2) preview à l'utilisateur, (3) sur confirmation, écriture .htaccess + apply search-replace + flush rewrite.

Bug n°5 — 27 erreurs Plugin Check WordPress.org

Symptôme : avant soumission à wordpress.org, l'outil officiel Plugin Check remontait 27 erreurs bloquantes : translators comments mal placés, $_POST/$_SERVER sans wp_unslash(), identifiants SQL non échappés, parse_url() au lieu de wp_parse_url(), error_log() non gardé.

Cause : codebase qui a grossi vite, conventions WordPress strictes qu'on connaissait mais qu'on n'avait pas appliquées systématiquement. Une partie héritée du SDK Freemius (qu'on ne touche pas), le reste à corriger côté Alesta.

Fix : passage en revue de toutes les erreurs avec un grep par règle, ajout systématique de sanitize_text_field( wp_unslash( $_POST[...] ) ), translators comments correctement placés avant chaque esc_html__() avec placeholder, esc_sql() sur les noms de tables/colonnes dans le module Search & Replace, error_log() wrappé dans if (defined('WP_DEBUG') && WP_DEBUG). Re-export Plugin Check : 0 erreur hors Freemius.

Les leçons

"

Tester en local sur MAMP ne suffit pas. Tester sur un staging représentatif de la production de nos utilisateurs (SiteGround derrière proxy SSL, Elementor Pro, WooCommerce chargé) est la seule façon d'attraper 80 % des bugs avant qu'ils ne sortent.

  1. Reproduire l'environnement utilisateur : pas de "ça marche chez moi", on a un staging SiteGround dédié maintenant.
  2. SSH + WP-CLI > clic dans l'admin : en 30 secondes on active 47 modules et on charge 12 pages représentatives. Impossible à la souris.
  3. Plugin Check avant chaque release : c'est l'outil officiel WordPress.org. Si ça passe localement chez nous, ça passera au review wp.org.
  4. Sanity checks défensifs partout : si une opération renvoie un résultat anormalement petit, on bail-out plutôt que de servir un truc cassé.
  5. Postmortems publics : vous lisez le 1er. Ça nous force à être honnêtes, et ça aide d'autres dev WordPress qui chercheront ces erreurs sur Google.

État au 14 mai 2026

Alesta AI Premium v1.3.6 est en cours d'upload sur Freemius. Alesta AI Free v1.2.11 est en cours de soumission à wordpress.org. Les deux versions partagent le même fix Minify/Mixed Content, mais Search & Replace et Trustpilot restent exclusifs à la Premium.

postmortem v1.3.6 debugging SSH PCRE Plugin Check
Partager : 𝕏 in ✉