Documentation 3DIS Optimizer

3DIS CFDB Optimizer, le plugin de réduction des lectures CFDB répétées.

Ce guide décrit l’installation, le réglage par contenu et le fonctionnement de 3DIS CFDB Optimizer. Version actuelle : 1.2.1 stable, mise à jour le 10 octobre 2026.

3DIS Optimizer 1.2.0 — ressources et réglages du site

Version publiée le 9 octobre 2026. Le plugin devient 3DIS Optimizer ; son identifiant technique reste 3dis-cfdb-optimizer afin de conserver licences et réglages.

Inventaire et tableau des ressources

Dans Outils → Optimizer — ressources, renseignez l’identifiant du contenu et cliquez sur Afficher. L’inventaire présente les ressources, leurs origines, leurs dépendances, l’action demandée et la dernière décision calculée. L’observation serveur ne remplace pas un test des menus et formulaires dans le navigateur.

Les choix proposés permettent de conserver, bloquer, différer ou retarder une ressource, ou de laisser le mode automatique décider. Bloquer un CSS ou un JavaScript ne supprime pas le HTML produit par l’extension. Le délai est compté depuis le début de navigation ; les scripts retardés conservent leur ordre et attendent leurs prédécesseurs. Une dépendance immédiate peut empêcher le différé.

Réglages globaux et exceptions

Les réglages peuvent s’appliquer au site, être hérités, personnalisés ou désactivés pour un contenu. Après enregistrement, purgez le cache de page si nécessaire et vérifiez le rendu public. La restauration reprend les réglages précédents. Les ressources inconnues ou partagées sont conservées par défaut.

Placer les styles admissibles avant le contenu.
Compléter les dimensions des images locales reconnues pour réserver leur emplacement.
Préparer puis utiliser les feuilles de polices locales.
Bloquer les fichiers CF7 reconnus si aucun formulaire n’est rendu, et les ressources d’éditeur reconnues si aucun éditeur n’est rendu.
Configurer les animations CSS par sélecteur ; les animations JavaScript se règlent sur leur script.

Prévoyez une exception pour les composants ajoutés après chargement par AJAX. Minification, regroupement, lectures AJAX et variantes d’images restent des fonctions distinctes avec leurs propres conditions.

Validation et mise à jour

La recette couvre notamment la sauvegarde réelle du tableau, les transformations de ressources et des parcours de formulaire. Sur un dossier fictif identique, les lectures CFDB sont passées de 84 à 60 ; les temps serveur variables ne démontrent pas une accélération systématique. Aucun score PageSpeed ni gain de durée n’est garanti.

La version 1.2.1 corrige la mise à jour AJAX individuelle lorsque le site héberge aussi son serveur de licences : le paquet autorisé est préparé avant la maintenance WordPress, puis son empreinte et sa taille sont revérifiées avant installation. Les contrôles de licence et de signature restent actifs. Le correctif a été testé sur 3dis-development.com ; la mise à jour native de 1.2.0 vers 1.2.1 a également réussi sur Deasy Life le 10 octobre 2026. Les mises à jour groupées, automatiques et WP-CLI ne sont pas couvertes par cette préparation.

Les sections historiques ci-dessous détaillent le moteur CFDB et les versions précédentes ; cette section présente les ajouts de la version 1.2.0.

Prérequis et compatibilité

Le moteur cible Contact Form DB de Michael Simpson 2.10.37, avec vérification des empreintes de onze fichiers reconnus. CFDB7 est un produit différent et n’est pas pris en charge. Les versions déclarées minimales sont WordPress 6.4 et PHP 7.4 ; toute la matrice de versions n’a pas été testée. Le multisite réel n’est pas certifié.

Contact Form 7 et Dynamic Text Extension (DTX) sont facultatifs pour le moteur. CF7 est nécessaire au test intégré des formulaires. Les appels DTX doivent passer par les shortcodes WordPress pour être interceptés. L’environnement de recette réel utilisait WordPress 7.1.2, PHP 8.5.10, MariaDB 11.4.13, CFDB 2.10.37, CF7 6.1.7 et DTX 5.0.7.

Installer et activer le plugin

Sauvegardez les fichiers et la base du site avant l’installation.
Dans Extensions → Ajouter une extension, téléversez l’archive du plugin, installez-la puis activez-la.
Ouvrez Extensions → 3DIS CFDB Optimizer — Licence. Saisissez votre clé, ou démarrez volontairement l’essai de quinze jours.
Dans Outils → 3DIS CFDB Optimizer, autorisez l’optimisation sur les contenus sélectionnés, puis enregistrez.
Activez individuellement les contenus concernés et contrôlez leurs valeurs avant et après.

L’activation de l’extension seule n’optimise pas toutes les pages. Une licence valide, l’autorisation globale et le réglage individuel doivent être réunis. Ne modifiez pas les fichiers du plugin CFDB.

Activer ou désactiver un contenu

Dans l’éditeur de la page, de l’article ou de l’événement, ouvrez les réglages du contenu puis le panneau Optimisations 3DIS. Cochez les actions souhaitées, notamment Optimiser les requêtes CFDB et enregistrez. Gutenberg affiche ce réglage dans sa barre latérale ; l’éditeur classique utilise une boîte dédiée. La case est décochée par défaut.

Le choix est enregistré pour ce contenu uniquement. Il n’existe pas d’activation collective par type, ni de liste d’identifiants à saisir. Décocher la case restaure le traitement natif sur ce contenu. Désactiver l’extension ou l’autorisation globale le restaure partout. Les archives et listes ne sont pas activées par le réglage d’un contenu singulier.

Tester un formulaire et comprendre les résultats

Dans les outils du plugin, sélectionnez un formulaire CF7 réel et choisissez les droits du compte connecté ou d’un visiteur non connecté. Lancez le test. Deux requêtes séparées rendent le formulaire, une sans optimisation et une avec. Aucun champ ni appel CFDB supplémentaire n’est créé. Le formulaire n’est pas envoyé.

Indicateur	Interprétation
Lectures CFDB	Shortcodes CFDB réellement exécutés pendant ce rendu.
Requêtes SQL CFDB	Requêtes de lecture visant la table CFDB pendant le rendu du formulaire.
Temps serveur	Durée de ce rendu seul, pas le chargement complet de la page.
Valeurs identiques	Comparaison par empreintes des sorties CFDB ; aucune donnée métier affichée.

Un formulaire sans CFDB n’a aucun gain à mesurer. Si les sorties diffèrent, le résultat n’est pas concluant. Les droits natifs restent applicables : le test visiteur peut ne produire aucune requête si CFDB refuse cet accès. Les scripts du navigateur, la soumission et le contexte de la page ne sont pas testés. Pour un formulaire dépendant d’une URL ou d’une page, complétez la mesure dans cette page réelle. Le test global du site n’est pas implémenté.

Fonctionnement et périmètre technique

Le filtre WordPress pre_do_shortcode_tag intercepte les appels cfdb-value éligibles. Un adaptateur dérivé de ExportToValue conserve les contrôles d’accès et le rendu natifs. La première lecture collecte les lignes ; les appels compatibles suivants utilisent des curseurs indépendants et leur propre projection de champs.

La clé de réutilisation tient compte de la sélection résolue, du site, de l’utilisateur, de ses rôles et capacités, de la langue et du fuseau. Un changement de site ou d’utilisateur, ou une écriture via wpdb, invalide la mémoire. Une intégration qui écrit autrement doit appeler do_action('threedis_cfdb_optimizer_invalidate'). Les écritures concurrentes d’une autre requête ne sont pas détectées : excluez les pages qui exigent une relecture immédiatement actualisée.

Le périmètre reconnu comprend un formulaire nommé unique, les projections show/hide, les filtres comparatifs sans fonctions et les options compatibles d’ordre, de limite et de rendu. Les expressions régulières, transformations, contenus encadrants, options inconnues et filtres SQL tiers inconnus conduisent au traitement natif. Cette prudence ne corrige pas les vulnérabilités éventuelles du code CFDB d’origine.

Budgets : 500 lignes par sélection, 32 sélections et environ 4 Mio de mémoire supplémentaire estimée. Un dépassement abandonne la collecte sans tronquer le rendu ni relancer la lecture en cours. Ces plafonds ne limitent pas le résultat initial déjà chargé par CFDB ni le texte final. Il n’y a pas de cache persistant de résultats CFDB ni de journal de leurs valeurs.

Cache de page et données personnelles

Le plugin demande de ne pas mettre les contenus optimisés en cache pleine page avec DONOTCACHEPAGE et des en-têtes adaptés. Vérifiez les exclusions de votre cache ou CDN, puis purgez les réponses concernées. Une réponse déjà servie sans PHP échappe au moteur. Les lignes réutilisées restent dans la seule requête PHP courante, sans partage entre visiteurs. Le service de licence ne reçoit pas les valeurs CFDB du moteur ou du test.

Licence, tâches planifiées et mises à jour

Le plugin utilise le service de licences 3DIS et un SDK isolé de celui des autres extensions. Les autorisations sont signées en RS256 et contrôlées avec une clé publique épinglée. Le cache local est lié au domaine ; l’autorisation doit être positive, non expirée et porter une date serveur signée datant de moins de sept jours, sans dépasser l’expiration de la licence.

La tâche 3dis_cfdb_optimizer_license_refresh prévoit une vérification quotidienne. En secours, la première visite exécutant PHP après 24 heures déclenche une requête locale HTTPS asynchrone, même si WP-Cron natif est désactivé. Cela fonctionne côté public et administration, sans attendre la réponse du serveur de licences pour rendre la page. Les pages entièrement servies par le cache ne déclenchent pas PHP. Sans visite ni cron externe, aucune tâche ne se réveille spontanément. Les appels locaux doivent être autorisés par l’hébergement.

La tolérance est limitée à sept jours depuis la dernière validation signée. Une révocation confirmée, une expiration connue ou une signature invalide restent bloquantes. Après une panne temporaire, les tentatives sont espacées d’au moins une heure ; un verrou évite les traitements simultanés. Une notice apparaît après deux jours de retard. Le bouton « Vérifier maintenant » reste disponible. La préparation des fichiers optimisés conserve sa propre planification, distincte de la licence.

À expiration, en cas de refus ou d’autorisation devenue trop ancienne, seule l’optimisation s’arrête. Les données et formulaires restent utilisables avec CFDB normal. Les offres annuelles prévoient 1, 5 ou 20 sites, mises à jour et assistance pendant la licence, avec renouvellement manuel. Le SDK contrôle les métadonnées signées et l’empreinte des archives ; le paquet stable est distribué par le serveur de versions 3DIS ; aucun paiement réel ni cycle complet de facturation n’a été exécuté dans la recette de performance.

Modules de la version 1.1.1

Les cases de l’éditeur activent les fonctions séparément. Les ressources conditionnelles, la minification, le regroupement CSS et le différé s’appuient sur des règles compatibles et un plan préparé. Un filtre tiers inconnu ou une ressource non éligible conserve le chemin natif. Le regroupement JavaScript universel n’est pas proposé.

Les lectures AJAX exigent un adaptateur serveur explicite ; le plugin n’intercepte pas tous les formulaires. Les images reconnues peuvent utiliser des tailles adaptées et des variantes WebP/AVIF selon les capacités du serveur. Les originaux, images prioritaires et exclusions sont conservés. Le cache des fichiers générés ne stocke pas les données métier CFDB.

Diagnostic des interactions

Depuis « Diagnostic des ressources et aperçu », lancez la vérification. Le plugin examine les réglages reconnus de LiteSpeed, WP Rocket et Autoptimize, les directives explicites de .htaccess et, sur demande, une page publique. Gzip ou cache ne signifient pas minification. Un indice est signalé comme tel ; la détection n’est pas universelle. Les messages recommandent un seul outil pour une même fonction, sans désactiver vos options automatiquement.

Recette du 29 septembre 2026

290 contrôles locaux et 19 contrôles serveur réussis. Après mises à jour, 50 lectures CFDB/DTX produisent toujours 3 requêtes et 50 valeurs identiques. Le secours de licence fonctionne par requête anonyme avec WP-Cron désactivé. Sept scénarios LiteSpeed répondent correctement ; dialogue, AJAX et images WebP fonctionnent sur ordinateur et à 390 pixels.

LiteSpeed 7.9.1 a été testé sur le site. WP Rocket et Autoptimize ont été couverts par simulations de leurs API. Ces contrôles ne constituent pas une garantie universelle de compatibilité ni une mesure globale avant/après de tous les modules. Aucun paiement, e-mail ou PDF réel n’a été généré.

Dépannage

L’optimisation ne se déclenche pas

Vérifiez successivement la compatibilité CFDB, la licence, l’autorisation globale et la case du contenu enregistré. Consultez ensuite les exclusions de cache et l’exécution des tâches planifiées. Une sélection non compatible conserve volontairement son fonctionnement natif.

Le résultat est différent selon l’utilisateur

Contrôlez les permissions CFDB et les variables du shortcode. N’élargissez pas les droits d’accès pour obtenir un meilleur chiffre. Comparez les deux modes avec le même utilisateur et les mêmes paramètres.

Les valeurs diffèrent entre les deux modes

Désactivez l’optimisation du contenu concerné. Notez les versions, les attributs du shortcode et les extensions impliquées ; transmettez au support un exemple anonymisé, sans clé de licence complète ni données personnelles de formulaire.

Désinstallation et retour arrière

Désactiver l’extension suffit à revenir au traitement CFDB natif. Avant suppression ou déplacement du site, libérez l’activation depuis l’écran de licence. La désinstallation supprime les options, tâches et métadonnées propres au plugin sur le site courant, sans effacer les soumissions CFDB. La désinstallation multisite n’est pas certifiée.

Ressources associées

Retrouvez les résultats du test réel et leur interprétation, la fiche de 3DIS CFDB Optimizer et le contact 3DIS pour une question d’intégration.

Architecture, intégration et maintenance — CFDB Optimizer

Référence : 1.1.1 · documentation vérifiée dans le code le 29 septembre 2026. Cette partie complète le guide d’utilisation. Les exemples doivent être adaptés puis testés sur un formulaire ou contenu de recette. Ils ne modifient pas automatiquement votre site.

Architecture et ordre d’exécution

Le point d’entrée charge la configuration et l’orchestrateur. ContentConfiguration lit les actions du contenu ; Orchestrator sélectionne les moteurs éligibles. Pour CFDB, Plugin intercepte les shortcodes compatibles, NativeExport conserve le rendu natif et RequestCache mutualise la sélection pendant la requête PHP. Compatibility vérifie les sources CFDB reconnues. Une incompatibilité provoque le retour au traitement natif.

Les ressources utilisent ContentInventory, AssetGraph, PlanJobs et PreparedPlan pour observer, préparer et valider un plan ; AssetRuntime applique les décisions. AssetTransforms prépare les transformations et ArtifactStore les fichiers générés. ImagePlans et ImageRuntime traitent les images éligibles. InteractionDiagnostics produit des avertissements sans changer les réglages concurrents. Licensing contrôle l’autorisation des moteurs.

Préparer un plan de ressources, pas à pas

Dans l’éditeur du contenu, cochez uniquement les actions nécessaires, puis enregistrez. Ouvrez Diagnostic des ressources et aperçu.
Lancez le diagnostic des interactions. Si un autre outil assure déjà une fonction, choisissez dans ses réglages et ceux de 3DIS lequel doit la réaliser.
Utilisez Observer le rendu natif. Pour le contexte public, choisissez Créer un lien d’observation visiteur et ouvrez ce lien dans une fenêtre privée déconnectée. Il est à usage unique et expire après quinze minutes.
Revenez au diagnostic. Pour chaque ressource, conservez le comportement natif, imposez Toujours conserver ou proposez un retrait justifié. L’observation ne démontre pas qu’un fichier est inutile. Les dépendances nécessaires et les ressources protégées restent conservées.
Pour les ressources compatibles, cochez Minifier, Différer après parsing ou indiquez un même groupe CSS. La transformation exige aussi l’action correspondante du contenu et, pour produire des fichiers, le cache des fichiers générés.
Vérifiez menus, fenêtres, formulaires, clavier et variantes mobiles. Cochez la confirmation de vérification, puis Enregistrer les décisions.
Cliquez Préparer maintenant et comparez Aperçu sans optimisation à Aperçu avec le plan. En cas d’anomalie, utilisez Suspendre le plan ou décochez l’action du contenu.

Le plan est lié au contexte observé, à la génération et à l’état du site. Sa validité est limitée à une journée. Une modification du contenu, du thème, d’une extension ou d’options partagées peut l’invalider. Les ressources ajoutées tardivement, non reconnues ou incompatibles gardent leur comportement natif ; le plugin ne reconstruit pas tout le site lors d’une visite publique.

Préparer les images

Ajoutez la classe CSS 3dis-optimize dans les réglages avancés du bloc Image concerné.
Activez les actions d’images utiles sur le contenu, puis préparez l’inventaire.
Dans Images sélectionnées, précisez si l’image est publique, prioritaire ou hors écran, choisissez une taille WordPress existante et, si nécessaire, un attribut sizes.
Pour une variante, choisissez WebP ou AVIF, largeur maximale et qualité. Le serveur doit disposer du codec correspondant. Enregistrez les réglages puis préparez le plan.
Contrôlez dimensions et rendu sur mobile. Gardez l’image principale prioritaire ; n’appliquez pas le différé à toutes les images.

Les fonds CSS, carrousels et blocs non reconnus ne sont pas transformés par cette sélection. Les originaux restent disponibles ; les variantes sont des fichiers dérivés.

Données, tâches et invalidation

Les actions sont enregistrées dans _threedis_cfdb_optimizer_actions. Le plan utilise _threedis_optimizer_plan, sa génération _threedis_optimizer_generation et l’état de tâche _threedis_optimizer_job. Les observations, règles, inventaires et diagnostics volumineux passent par PlanData, dans des options threedis_optimizer_data_… sans chargement automatique. Évitez toute édition directe en base.

La tâche threedis_optimizer_build est prévue après enregistrement. Un verrou limite les préparations simultanées ; après trois échecs, l’état devient Échec. Préparer maintenant permet une exécution administrative même lorsque WP-Cron est désactivé. Le secours automatique de licence n’exécute pas cette tâche à sa place. Le dossier uploads/3dis-optimizer-cache contient les artefacts statiques, pas les résultats CFDB.

Pour invalider les lectures CFDB après une écriture réalisée hors de wpdb, utilisez do_action('threedis_cfdb_optimizer_invalidate');. Une écriture dans une autre requête PHP ne peut pas invalider rétrospectivement la mémoire de la requête courante.

Exemple d’adaptateur de lecture AJAX

AjaxReads est une API PHP : elle ne crée aucune route et ne met pas en cache toutes les réponses AJAX. Le code appelant conserve la validation des paramètres, le nonce et les droits de sa propre route. L’autorisation de l’adaptateur est contrôlée même en cas de réutilisation. Enregistrez le callback sur threedis_optimizer_register_reads avant init : le plugin charge alors la classe et appelle ce hook. Appelez ensuite read() dans votre route validée. Placez l’intégration dans votre extension métier ; ne modifiez pas le plugin distribué.

use ThreeDIS\CFDBOptimizer\AjaxReads;

add_action('threedis_optimizer_register_reads', static function (): void {
    AjaxReads::register(
        'titre_contenu',
        static function (array $params): bool {
            return current_user_can('read_post', (int) $params['id']);
        },
        static function (array $params): array {
            return ['titre' => get_the_title((int) $params['id'])];
        },
        static function (array $params): array {
            return ['modification' => get_post_modified_time('U', true, (int) $params['id'])];
        }
    );
});

// Dans votre callback de lecture, après init et ses contrôles :
// $resultat = AjaxReads::read('titre_contenu', ['id' => 123], 456);

123 désigne le contenu lu et 456 celui dont les réglages s’appliquent. La réutilisation reste limitée à la requête PHP courante, à 64 entrées et environ 1 Mio ; les objets ne sont pas conservés. Utilisez AjaxReads::invalidate() après une écriture métier hors des requêtes SQL observées. Sans activation de l’action, la lecture autorisée s’effectue normalement.

Mise à jour et retour arrière

Sauvegardez base, réglages et archive de la version installée ; relevez le numéro et l’empreinte du paquet.
Installez la nouvelle version par WordPress, puis contrôlez la licence et le test de formulaire avec comparaison des valeurs.
Réobservez et préparez les plans invalidés. Contrôlez séparément ressources, images et interactions réelles.
En cas de régression, activez l’arrêt d’urgence ou désactivez l’action touchée. Pour revenir à l’ancien code, restaurez l’archive connue et, si une migration l’exige, la sauvegarde cohérente. Réappliquer un ancien ZIP n’annule pas nécessairement une migration.

Pour diagnostiquer : notez version, contenu, action, contexte connecté/visiteur, état du plan, message de licence et étapes de reproduction. N’incluez ni valeurs CFDB privées ni clé de licence. Les résultats de recette décrits plus haut ne remplacent pas la recette de vos intégrations.

Retrouver les autres documentations 3DIS · Assistance technique

CFDB Optimizer 1.1.2 — Fiabilisation des mises à jour sous licence

Publication du 2 octobre 2026. La recherche conserve une cadence de douze heures. WordPress affiche la version disponible ; seul l’administrateur décide de cliquer sur « Mettre à jour ». Aucun réglage de mise à jour automatique n’est activé par cette correction.

La recherche vérifie les métadonnées signées et les conserve 24 heures, sans y stocker le jeton de téléchargement. Un jeton neuf est demandé au moment du téléchargement. La licence, la version, la signature, la destination, l’expiration, la taille et l’empreinte SHA-256 sont vérifiées ; un refus ou un fichier altéré empêche l’installation.

Le bouton de vérification de licence relance aussi la recherche, avec une limite d’une fois par minute et un verrou contre les appels concurrents. Une visite de l’administration peut effectuer le contrôle arrivé à échéance même lorsque WP-Cron est désactivé. Cela ne modifie pas la configuration cron de l’hébergement. Les anciens liens signés conservés dans une annonce WordPress ne sont plus réutilisés.

Les licences, données et réglages existants sont conservés. Shop et PAYMENT embarquent désormais chacun leur copie isolée du SDK pour éviter une dépendance à l’ordre de chargement. Multistep 0.4.10 possédait déjà ce mécanisme ; les versions associées sont Shop 0.3.8, PAYMENT 1.1.2, Multifiles 1.2.1 et CFDB Optimizer 1.1.2.

Sur 3dis-development.com, les quatre candidats ont conservé leur licence valide ; les quatre téléchargements officiels ont été vérifiés, puis les quatre mises à jour manuelles natives vers les versions stables ont réussi. Les tests locaux couvrent aussi le refus des liens expirés, des fichiers corrompus et des autorisations refusées. Ces contrôles concernent le mécanisme de mise à jour, pas une nouvelle recette de tous les paiements ou formulaires.

Limitation historique des versions antérieures à 1.2.1 : si le site héberge lui-même son serveur de licences, la maintenance pendant une mise à jour AJAX peut interrompre la demande de jeton. Le parcours WordPress dans une page complète a été validé sur cette configuration. Ne pas contourner un refus en exposant publiquement le ZIP ; utiliser le paquet officiel autorisé et le téléversement administrateur si nécessaire. Sauvegarder le site avant toute mise à jour.