Formulaire

Un contact, une recherche ou un commentaire ne sont jamais transmis champ par champ : ils sont regroupés dans un même conteneur qui décide comment et vers où l’ensemble des données saisies doit voyager une fois l’utilisateur prêt à valider.

Anatomie et fonctionnement dans WordPress

Les attributs action et method définissent la destination et la méthode d’envoi, généralement GET pour une recherche ou POST pour une donnée sensible :

<form action="/recherche" method="get" role="search">
  <label for="s">Rechercher</label>
  <input type="search" id="s" name="s">
  <button type="submit">Chercher</button>
</form>

WordPress traite en interne de nombreux formulaires de cette façon, notamment via le fichier wp-comments-post.php pour les commentaires, ou admin-post.php pour un formulaire côté public géré par une extension.

Pièges fréquents

• Un formulaire envoyé en méthode POST vers une extension WordPress doit systématiquement inclure un champ nonce généré par wp_nonce_field(), sous peine d’être rejeté par une vérification de sécurité côté PHP.
• Deux champs partageant le même attribut name à l’intérieur d’un même formulaire écrasent leur valeur mutuellement à la soumission, sauf à utiliser une notation en tableau comme name="options[]".
• La méthode GET expose les valeurs saisies directement dans l’URL générée, ce qui la rend inadaptée à un mot de passe ou toute autre donnée sensible qui devrait rester hors des journaux du serveur.
• L’attribut novalidate désactive la validation native du navigateur sur l’ensemble du formulaire, un réglage parfois nécessaire quand un script personnalisé gère lui-même l’ensemble des messages d’erreur.