Envoyer un formulaire HTML par e-mail sans PHP

Remplacez l'action du formulaire, qui pointe vers votre script PHP, par l'URL d'un backend de formulaires, gardez les noms de champs et supprimez le script. Le backend fait ce que faisait mail(), plus ce qu'il n'a jamais bien fait : filtrer le spam, stocker et envoyer des e-mails qui n'atterrissent pas dans les spams. Cela fonctionne sur les hébergeurs statiques où PHP ne peut pas tourner du tout.

Ce qui change ici

La plupart des formulaires de contact PHP sont les mêmes vingt lignes, copiées d'un tutoriel il y a des années. Ils lisent $_POST, construisent une chaîne, appellent mail() et redirigent. En voici un typique :

<?php
$name = $_POST["name"];
$email = $_POST["email"];
$phone = $_POST["phone"];
$message = $_POST["message"];

$to = "hello@example.com";
$subject = "Website enquiry from $name";
$body = "Name: $name\nEmail: $email\nPhone: $phone\n\n$message";
$headers = "From: $email\r\nReply-To: $email";

if (mail($to, $subject, $body, $headers)) {
  header("Location: /thanks.html");
} else {
  echo "Sorry, something went wrong.";
}

Il a l'air inoffensif, et il fonctionnait quand il a été écrit. Aujourd'hui, il casse de quatre façons, et seule la première est visible :

Vous pourriez corriger chaque point : valider chaque valeur, envoyer via un fournisseur SMTP avec une bibliothèque comme PHPMailer, configurer SPF et DKIM pour votre domaine, ajouter un honeypot et une limite de débit, et tout journaliser dans une base de données. C'est un projet raisonnable si vous faites déjà tourner du PHP. Sinon, confiez ce travail à un backend de formulaires.

Sortir le formulaire de PHP

Gardez les noms de champs exactement tels quels. Seule l'action change, plus deux inputs masqués :

<form action="/contact.php" method="post">
  <input name="name" required />
  <input name="email" type="email" required />
  <input name="phone" type="tel" />
  <textarea name="message" required></textarea>
  <button>Send</button>
</form>

<form action="https://ikiform.com/f/frm_xxxxxxxxxxxxxxxx" method="post">
  <input name="name" required />
  <input name="email" type="email" required />
  <input name="phone" type="tel" />
  <textarea name="message" required></textarea>
  <input type="hidden" name="_redirect" value="https://example.com/thanks.html" />
  <input name="_gotcha" type="text" tabindex="-1" autocomplete="off" hidden />
  <button>Send</button>
</form>

Puis faites correspondre chaque chose que faisait le script à l'endroit où elle se trouve désormais :

• Ajoutez votre domaine dans Allowed domains. _redirect ne fonctionne que pour une URL https: sur l'un de ces domaines.
• Supprimez contact.php du serveur une fois le nouveau formulaire en place. Un script oublié reste un relais mail ouvert pour les bots qui se souviennent de l'URL.
• Si vous êtes passé à un hébergeur statique, l'ancienne URL /contact.php n'existe plus. Les bots qui envoient directement dessus reçoivent un 404, et c'est très bien.

Vérifiez que tout fonctionne

1. Dans Allowed domains du formulaire, ajoutez le domaine de votre site, plus localhost pendant le développement. Laissez vide pour accepter les envois de partout.
2. Envoyez le formulaire sur votre page en ligne. Vous arrivez sur votre ancienne thanks.html.
3. Ouvrez Submissions dans le tableau de bord. La nouvelle soumission y est, avec tous les champs envoyés.
4. Ouvrez l'e-mail. Il vient d'Ikiform, pas de l'adresse du visiteur, et n'est pas dans les spams. Ajoutez l'expéditeur à vos contacts pour que les suivants n'y soient pas non plus.
5. Cliquez sur Reply. L'adresse du visiteur est sur la ligne To.
6. Envoyez avec le honeypot rempli, _gotcha=bot. L'envoi reçoit quand même une réponse de succès, mais la soumission est stockée comme spam et n'envoie ni e-mail ni webhook.

Pièges

• Anciens noms de formulaire avec crochets. Les formulaires PHP utilisent souvent des noms comme contact[email]. Ikiform les stocke tels quels, mais l'adresse de réponse ne vient que d'un champ nommé email ou de quelques variantes proches. Renommez le champ, ou ajoutez _replyto.
• L'objet ne peut pas inclure le nom. L'objet du script contenait le nom du visiteur. L'objet de la notification est fixe, et _subject est transmis aux webhooks et à l'API sans changer l'e-mail.
• Encodage des caractères. Les scripts mail() abîmaient souvent les accents parce qu'ils ne définissaient jamais de charset. L'e-mail d'Ikiform est en UTF-8, les noms dans n'importe quelle écriture arrivent donc intacts.
• Plusieurs adresses dans $to. Une liste séparée par des virgules dans le script devient des destinataires distincts dans le tableau de bord. Les adresses extérieures confirment par lien avant de recevoir quoi que ce soit. Voir plusieurs destinataires.

Si quelque chose ne va pas

Questions