Le WordPress d'aujourd'hui, décodé pour les développeurs

Éditeur de site (FSE)

Formulaire de devis BTP posté vers une route REST, dans un template

Envoyer les données d'un formulaire de devis directement vers une route REST personnalisée depuis un template du Site Editor, pour un artisan du bâtiment.

Par WordPress Développement • 24 février 2023 • 5 min de lecture • Aucun commentaire
Formulaire de devis BTP posté vers une route REST, dans un template

register_rest_route() : cette fonction, disponible depuis les débuts de l’API REST de WordPress, permet de créer un point d’entrée sur mesure sans dépendre d’une extension de formulaire complète. Pour un artisan du bâtiment qui veut collecter des demandes de devis chiffrées (type de travaux, surface, délai souhaité) directement depuis son site, c’est une option souvent plus légère qu’une extension généraliste dimensionnée pour des besoins bien plus larges.

Le principe retenu ici : un formulaire HTML simple, inséré comme bloc personnalisé dans un gabarit de page du Site Editor, qui poste ses données en JavaScript vers une route REST déclarée côté thème, laquelle enregistre la demande comme un article du type demande_devis.

Déclarer la route REST

La route se déclare classiquement dans le fichier functions.php du thème, accrochée au hook rest_api_init. Elle expose un espace de noms propre au projet, pour éviter toute collision avec d’autres routes existantes :

add_action( 'rest_api_init', function() {
    register_rest_route( 'artisan-btp/v1', '/devis', array(
        'methods'             => 'POST',
        'callback'            => 'enregistrer_demande_devis',
        'permission_callback' => '__return_true',
        'args'                => array(
            'type_travaux' => array( 'required' => true, 'type' => 'string' ),
            'surface'      => array( 'required' => true, 'type' => 'number' ),
            'email'        => array( 'required' => true, 'type' => 'string', 'format' => 'email' ),
        ),
    ) );
} );

Le réglage permission_callback à __return_true ouvre la route à tout visiteur non authentifié, ce qui est attendu pour un formulaire public. C’est précisément ce point qui impose une validation rigoureuse côté serveur, puisqu’aucune barrière d’authentification ne filtre les requêtes en amont.

Valider et enregistrer la demande

L'essentiel à retenir : Une route REST déclarée avec register_rest_route ; Validation des champs côté serveur avant enregistrement ; Le formulaire reste un bloc HTML personnalisé simple

La fonction de rappel reçoit un objet WP_REST_Request, dont les paramètres ont déjà été validés selon le schéma déclaré dans args (type, présence obligatoire, format d’e-mail). Il reste à assainir les valeurs avant de les enregistrer, puis à créer l’article correspondant :

function enregistrer_demande_devis( WP_REST_Request $requete ) {
    $type_travaux = sanitize_text_field( $requete->get_param( 'type_travaux' ) );
    $surface      = absint( $requete->get_param( 'surface' ) );
    $email        = sanitize_email( $requete->get_param( 'email' ) );

    if ( ! is_email( $email ) ) {
        return new WP_Error( 'email_invalide', 'Adresse e-mail non valide.', array( 'status' => 400 ) );
    }

    $id_demande = wp_insert_post( array(
        'post_type'   => 'demande_devis',
        'post_status' => 'private',
        'post_title'  => sprintf( 'Devis %s (%s)', $type_travaux, $email ),
    ) );

    update_post_meta( $id_demande, 'devis_surface', $surface );
    update_post_meta( $id_demande, 'devis_email', $email );

    return new WP_REST_Response( array( 'succes' => true ), 201 );
}

Protéger la route contre les soumissions automatisées

Une route ouverte à tout visiteur non authentifié attire tôt ou tard des robots de soumission automatique. Deux protections complémentaires limitent ce risque sans complexifier l’expérience du visiteur légitime : un champ « piège » invisible (un champ caché que seul un robot remplirait) vérifié côté serveur, et une limitation du nombre de requêtes par adresse IP sur une fenêtre de temps courte, implémentée via un compteur stocké en transitoire WordPress.

$compteur = get_transient( 'devis_ip_' . $_SERVER['REMOTE_ADDR'] );
if ( $compteur >= 5 ) {
    return new WP_Error( 'trop_de_requetes', 'Trop de demandes, réessayez plus tard.', array( 'status' => 429 ) );
}
set_transient( 'devis_ip_' . $_SERVER['REMOTE_ADDR'], (int) $compteur + 1, HOUR_IN_SECONDS );

Le formulaire côté gabarit

Le formulaire lui-même reste un bloc HTML personnalisé, inséré dans le gabarit de page dédié à la demande de devis. Le script associé intercepte la soumission et poste les données en JSON vers la route déclarée, sans rechargement de page :

document.querySelector('#formulaire-devis').addEventListener('submit', async function (evenement) {
    evenement.preventDefault();
    const reponse = await fetch('/wp-json/artisan-btp/v1/devis', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({
            type_travaux: document.querySelector('#type_travaux').value,
            surface: document.querySelector('#surface').value,
            email: document.querySelector('#email').value,
        }),
    });
    if (reponse.ok) {
        document.querySelector('#confirmation').textContent = 'Demande envoyée.';
    }
});

Ce que cette solution ne traite pas

L’envoi d’un e-mail de confirmation automatique à l’artisan ou au client, souvent attendu dans un formulaire professionnel, sort volontairement du périmètre de cet article, qui se concentre sur l’enregistrement structuré de la demande dans WordPress.

  • Une route REST déclarée à la main donne un contrôle total sur la validation et le format des données.
  • Elle évite l’installation d’une extension complète pour un besoin de collecte relativement simple.
  • Elle exige, en contrepartie, une vigilance sur la sécurité que gère habituellement une extension mature.

En résumé

Une route REST déclarée sur mesure, couplée à un formulaire HTML simple dans un gabarit du Site Editor, offre à un artisan du bâtiment une collecte de devis fonctionnelle sans extension supplémentaire. La rigueur de la validation côté serveur reste la condition non négociable de cette approche.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Partager :

À propos de l'auteur

WordPress Développement

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi