Formulaires de contact et messages

Contact Form et Contact Messages sont des fonctionnalités de premier ordre de WebBlocks CMS. Utilisez le bloc natif contact_form pour les pages de contact plutôt que Trusted HTML, un balisage de formulaire brut ou des solutions de repli mailto:.

Ce guide regroupe le comportement de Contact Form et de Contact Messages destiné à l'utilisateur, documenté dans les contrats de blocs, les contrats de rendu public, la documentation de l'Internal Content API et le README. Il ne définit pas de nouveau comportement d'exécution.

Le bloc Contact Form affiche un véritable formulaire public et enregistre les messages acceptés dans le CMS. Contact Messages offre aux administrateurs un écran de revue de ces envois, comprenant le statut, les signaux de revue du spam, le statut de notification et les détails sûrs des échecs de remise.

Le CMS traite le stockage et la notification par e-mail comme deux préoccupations distinctes :

• les envois réels acceptés sont stockés avant toute tentative de notification
• la notification peut réussir, échouer ou être ignorée sans changer le fait que le CMS a accepté l'envoi public
• les visiteurs publics doivent voir un retour générique de succès ou de validation, et non le score de spam ou les détails internes de la remise

Ajoutez le bloc depuis le sélecteur de blocs du Page Builder. Le handle natif du bloc est :

Le bloc Contact Form n'est pas un conteneur d'enfants. Il détient la surface publique du formulaire et n'accepte pas de blocs de contenu imbriqués comme modèle de composition normal.

Une page de contact typique utilise du contenu structuré autour du formulaire natif :

Les outils IA/opérateur doivent construire le même type de structure une fois que la découverte en direct a confirmé les handles disponibles. Ils ne doivent pas créer de formulaires avec Trusted HTML, un balisage <form> brut ou des liens mailto: lorsque contact_form existe dans l'installation CMS cible.

Le texte visible est traduisible :

• title ou titre
• content ou texte d'introduction
• submit_label
• success_message

Les réglages opérationnels partagés se trouvent dans les paramètres du bloc :

• recipient_email
• send_email_notification
• store_submissions

Gardez le texte éditorial et le routage opérationnel séparés. Le texte du formulaire peut varier selon la langue (locale), tandis que les réglages de destinataire et de notification restent partagés pour le bloc.

Le moteur de rendu public produit un formulaire natif du navigateur qui envoie les données à :

Le formulaire est protégé par CSRF et valide les champs habituels du visiteur.

Champs obligatoires :

• name
• email
• message

Champ facultatif :

• subject

Champ de contrôle antispam généré par le moteur de rendu :

• _form_check_name métadonnées signées
• form_check_{token} champ de contrôle généré

Le moteur de rendu crée ces champs automatiquement. Ne les créez pas manuellement dans le contenu, en HTML brut ou dans les charges utiles de l'API. Le champ de contrôle ne fait pas partie de la saisie normale du visiteur, et l'ancien champ website n'est plus le contrat public de Contact Form.

Les envois dont le champ de contrôle est rempli reçoivent le même comportement générique de succès qu'un envoi accepté normal, mais ils ne sont ni stockés ni suivis d'une notification. Les envois automatisés très rapides sont traités de la même manière. Les visiteurs publics ne doivent pas recevoir de diagnostics de spam ou de remise.

Les envois réels acceptés sont stockés avant toute tentative de notification par e-mail.

Chemin d'administration :

Contact Messages est un écran de revue pour administrateurs. Ce n'est ni une liste publique ni une API publique de remise.

L'écran d'administration permet aux utilisateurs du CMS d'examiner les envois au niveau d'un guide utilisateur :

• le statut du message, par exemple nouveau, lu, répondu, archivé ou spam
• le contexte de la page d'origine lorsqu'il est disponible
• le score de spam et les libellés de motif de spam pour la revue
• si la notification a été ignorée, envoyée, a échoué ou est en attente
• les détails sûrs de l'échec lorsque la remise de la notification échoue

Le statut de notification par e-mail concerne uniquement le comportement de la notification :

• Sent signifie que le CMS a remis le message au transport de messagerie configuré sans exception. Cela ne garantit pas la remise dans la boîte de réception.
• Failed signifie qu'un envoi réel de notification a été tenté et que Laravel a signalé une exception. Le détail enregistré est assaini et ne doit pas contenir de mots de passe, de jetons, de .env brut ni de traces de pile.
• Skipped signifie que la notification n'a pas été tentée, généralement parce que le bloc l'a désactivée.
• Not configured signifie que la notification n'a pas été tentée parce qu'aucun destinataire n'était disponible, que le mailer est log, array ou null, ou que les réglages SMTP sont incomplets au point de rendre la remise sortante impossible.
• Pending est réservé aux enregistrements pour lesquels aucune tentative de notification ni résolution n'a encore eu lieu.

Les messages enregistrés plus anciens peuvent avoir un état de notification déduit des anciens champs d'envoi et d'erreur. Le CMS ne réécrit pas automatiquement ces enregistrements historiques.

Contact Messages suit également le comportement partagé des listes d'administration pour la suppression groupée des éléments sélectionnés, lorsqu'elle est disponible. Considérez la suppression comme une action de nettoyage administratif, et non comme une partie du traitement normal du formulaire public.

Le traitement du spam comporte deux couches.

La couche du champ de contrôle généré par le moteur de rendu procède à un rejet immédiat :

• le champ masqué généré form_check_{token} doit rester vide pour les visiteurs normaux
• les envois dont le champ de contrôle est rempli reçoivent un succès générique
• les envois dont le champ de contrôle est rempli ne sont pas stockés
• les envois dont le champ de contrôle est rempli ne déclenchent pas de notification

Les envois qui passent le champ de contrôle généré peuvent tout de même être notés de façon prudente. Exemples actuels de signaux de notation :

• densité de liens élevée ou liens multiples
• langage de prospection commerciale
• combinaisons génériques d'objet et de message de style commercial
• envois répétés depuis la même adresse IP

Le spam noté est volontairement conservé avec le statut spam pour la revue par l'administrateur. Ne présentez pas la suppression automatique du spam comme le comportement actuel. Un seuil configurable de rejet automatique n'est qu'une orientation future possible, après observation des données de production.

La notification de Contact Form utilise cet ordre de destinataires :

1. recipient_email au niveau du bloc
2. Le destinataire Contact par défaut du site courant, défini dans Edit Site -> Contact
3. CONTACT_RECIPIENT_EMAIL
4. MAIL_FROM_ADDRESS en dernier repli sûr

La réussite du stockage est distincte de la réussite de la notification. Une réponse publique de succès signifie que le CMS a accepté le flux du message, pas nécessairement que la remise de l'e-mail a réussi. Les administrateurs doivent consulter Contact Messages pour le statut de notification et les détails sûrs des échecs.

Les notifications de Contact Form utilisent la remise de courrier de Laravel. Les réglages SMTP typiques dans .env sont :

MAIL_* contrôle le transport de courrier de Laravel. MAIL_FROM_ADDRESS est l'adresse d'expéditeur sûre par défaut et le dernier repli sûr pour le destinataire. CONTACT_RECIPIENT_EMAIL est facultatif et n'est utilisé que lorsque les destinataires du bloc et du site sont vides. Pour le routage normal du site, préférez le destinataire Contact au niveau du site, dans Site -> Edit -> Contact.

Utilisez un mailer sortant réel tel que SMTP pour les notifications en production. MAIL_MAILER=log, MAIL_MAILER=array et MAIL_MAILER=null sont utiles en développement ou pour les tests, mais Contact Messages les affiche comme non configurés plutôt qu'envoyés, car aucune notification sortante réelle n'a été tentée.

Après avoir modifié les réglages de messagerie de .env sur une installation de production ou de type paquet, videz la configuration mise en cache lorsque la mise en cache de la configuration peut être active :

Pour le développement local, utilisez un collecteur SMTP local ou un compte SMTP de test fiable. Évitez de tester la remise des contacts sur des boîtes personnelles ou de production, sauf si l'opérateur a délibérément configuré cet environnement.

La commande de diagnostic est :

Utilisez l'ID d'un bloc Contact Form précis pour examiner le repli de destinataire de ce bloc :

N'utilisez une vérification d'envoi SMTP contrôlée que lorsque l'adresse de test cible est intentionnelle :

Les diagnostics ne doivent pas afficher de mots de passe, de jetons, de secrets de messagerie ni de configuration sensible brute. Les détails des notifications échouées, ignorées et non configurées peuvent être consultés depuis Contact Messages. Considérez Contact Messages comme la source de vérité pour les envois stockés et leur statut de notification.

Avant de publier ou d'annoncer une page de contact publique :

1. Vérifiez que la connexion administrateur fonctionne.
2. Vérifiez que l'identité du site et les réglages de domaine sont corrects.
3. Configurez la remise MAIL_* ou les réglages de messagerie système approuvés.
4. Configurez le destinataire Contact, de préférence sous Site -> Edit -> Contact.
5. Exécutez php artisan contact:mail-diagnose.
6. Prévisualisez ou publiez une page contenant le bloc natif contact_form.
7. Envoyez un message de test avec nom, e-mail, objet et message.
8. Vérifiez que /webadmin/contact-messages affiche le message stocké.
9. Examinez le statut de notification et les éventuels détails sûrs de l'échec.

Si la notification échoue mais que le message est stocké, traitez cela comme un problème de remise de courrier, et non comme un échec d'envoi du formulaire public.

L'Internal Content API est destinée aux outils IA/opérateur de confiance. Ce n'est pas une API publique de remise ni une intégration avec un fournisseur d'IA.

Les outils IA/opérateur doivent commencer par la découverte en direct :

Utilisez ensuite les liens découverts pour les contrats courants :

GET /webadmin/api/examples/contact-page illustre l'usage natif de contact_form. Les outils IA/opérateur ne doivent pas deviner les handles ni construire des formulaires de contact avec Trusted HTML, un balisage de formulaire brut ou des liens mailto: lorsque le bloc natif Contact Form est disponible.

L'application de contenu reste orientée brouillon et ne publie pas par défaut. Les opérateurs doivent valider les plans, ne les appliquer qu'après approbation explicite, prévisualiser la page en brouillon et laisser la publication à une personne ou à un flux de travail explicitement approuvé.

• Contrats de types de blocs
• Balisage de rendu public des blocs
• Contrats du moteur de rendu
• Internal Content API
• Découverte de l'API
• Guide de création de pages avec l'IA
• Inventaire des fonctionnalités