Formulaire conversationnel et page dédiée

Extension payante. Un formulaire peut se présenter une question par écran, et occuper une page WordPress dépouillée de son thème.

Ce document décrit ce que le module garantit et ce qu’il refuse. Le guide utilisateur en donne la version courte, dans la section « Une question à la fois ».

Le principe, et ce qu’il évite

Le découpage en écrans a lieu côté serveur. Le module recompose les pages du formulaire — une question par page — et le balisage produit est celui d’un formulaire multi-pages ordinaire.

C’est toute la décision d’architecture, et elle se lit à l’envers : ce que le module ne contient pas. Aucune gestion d’étapes, aucune prise de focus, aucune progression, aucune validation avant de quitter un écran, aucun saut des écrans vidés par la logique conditionnelle. Tout cela existe dans le cœur, pour les formulaires multi-pages, et fonctionne depuis des années. Le réécrire aurait créé une seconde navigation, qui aurait divergé de la première au premier correctif.

Le réglage vit dans les réglages du formulaire, sous conversation :

{
  "conversation": {
    "enabled": true,
    "shell": "neutral",
    "title": "Parlons de votre projet",
    "description": "Trois questions, deux minutes.",
    "logo_id": 42,
    "accent": "#2271b1",
    "background": "#ffffff"
  }
}

Sans JavaScript

Le visiteur voit un formulaire multi-pages complet : toutes les questions sont dans la page, les boutons d’étape restent masqués, et l’envoi se fait d’un bloc.

Cette version dégradée n’a demandé aucun code. Elle est la conséquence directe du choix précédent : puisque le balisage est celui d’un multi-pages ordinaire, il se comporte comme tel quand le script ne s’exécute pas.

Comment les écrans se composent

Une question, un écran.
Un bloc de texte ou un titre de section n’est pas une question. Seul, il ferait un écran dont on ne peut rien faire qu’avancer. Il est rattaché à la question qu’il introduit — ce qui est son rôle. En queue de page, il n’introduit plus rien : c’est une conclusion, et elle a son écran.
Un champ caché n’a pas d’écran. Il voyage sur le premier de sa page, parce qu’il doit rester dans le formulaire pour être soumis.
Le règlement se présente en dernier. Demander de payer avant d’avoir fini de répondre fait abandonner, et c’est la recommandation explicite du plan.
Les sauts de page restent des frontières. Les écrans se composent à l’intérieur de chaque étape existante : un formulaire déjà découpé garde son découpage, finement redécoupé. Le traverser reviendrait à défaire un choix que quelqu’un a fait.
Une page sans question reste telle quelle. La redécouper produirait des écrans vides.

Le titre d’une étape ne s’affiche que sur son premier écran. Le répéter ferait annoncer « Vos coordonnées » cinq fois de suite à un lecteur d’écran ; les écrans suivants reçoivent le repli du cœur — « Étape 3 sur 12 » — qui est l’information utile à ce moment-là.

Accessibilité

Tout vient du cœur, et se trouve donc déjà éprouvé :

chaque écran est un fieldset avec sa légende, sur laquelle le focus se porte au changement d’étape — déplacé, jamais piégé ;
la progression est une barre et une phrase en direct, « Étape 3 sur 12 » ;
les boutons sont de vrais button, pas des liens déguisés ;
les erreurs restent associées à leur champ.

Le module n’ajoute que deux gestes :

Entrée fait avancer, sauf dans une zone de texte où elle insère une ligne, sur un bouton ou un lien où elle les actionne, et sur le dernier écran où elle soumet. Maj+Entrée est toujours laissée au navigateur.
L’écran suivant revient sous les yeux par un défilement, immédiat si le système demande qu’on bouge le moins possible. L’animation d’apparition disparaît alors entièrement.

La page dédiée

Un gabarit de page, choisi dans « Attributs de la page » : SolisForms — page dédiée. L’administrateur crée une page ordinaire, y insère le formulaire, et choisit ce gabarit.

Pas d’URL à nous. Une adresse servie hors du cycle de WordPress perd les réécritures, les redirections, le cache de page, les plans de site, les en-têtes de sécurité du site et la langue courante. Une page garde tout cela — avec son adresse, son référencement et ses droits — et le gabarit ne retire que le thème.

Pas d’iframe, que le plan exclut. Elle isolerait le formulaire du document : focus piégé au passage de la bordure, hauteur à recalculer en permanence, cookies tiers, et un lecteur d’écran qui annonce « cadre » avant chaque question.

Le gabarit appelle wp_head() et wp_footer(). Sans eux, ni feuille de style du plugin, ni script public, ni jeton de soumission rafraîchi — c’est l’erreur classique du genre, et elle produit un formulaire muet.

La coque

Deux apparences. theme garde le décor du site : un formulaire inséré au milieu d’un article n’a aucune raison d’effacer l’article. neutral ne vaut que sur une page portant le gabarit dédié — et c’est le gabarit, non ce réglage, qui retire le décor.

L’en-tête — logo, titre, introduction — n’apparaît que s’il est renseigné. Le titre est un h2 : un formulaire inséré dans un article n’est pas le titre de cet article, et deux h1 dans une page sont une erreur de structure qu’un lecteur d’écran signale. Le logo porte un texte alternatif vide : il est décoratif, le nom figurant juste à côté en toutes lettres.

Les couleurs sont validées, pas assainies. Elles finissent dans un attribut style, sous forme de propriétés personnalisées. Une valeur qu’on nettoierait laisserait passer ce que le nettoyage n’a pas prévu ; une valeur qui doit correspondre à #rrggbb ou ne pas exister du tout ne laisse rien passer. Une couleur refusée retombe sur celle du thème, ce qui est toujours affichable.

Les deux points d’extension du cœur

Ce module a demandé deux filtres au cœur, et aucun code spécifique dans celui-ci :

solis_forms_form_pages recompose les pages avant le rendu ;
solis_forms_form_markup enveloppe le balisage produit.

Ils sont publics et documentés dans hooks-reference.md. Les deux revalident ce qu’on leur rend : une extension qui se trompe ne doit pas faire disparaître le formulaire d’une page publique.

Ce que le module ne fait pas

Ni éditeur visuel libre, ni URL sur mesure, ni test A/B, ni conversation automatisée, ni vidéo, ni branchement arbitraire — la logique conditionnelle du cœur reste le seul moyen de faire dépendre une question d’une réponse.

Il ne touche ni aux validations, ni aux calculs, ni aux paiements, ni à la reprise de saisie, ni à la soumission : ce sont les mêmes qu’un formulaire ordinaire, puisque c’est le même formulaire.