Cours WordPress — Semaine 6

FORMATION WORDPRESS · MODULE 06/08 · 10 HEURES

Relier WordPress au JavaScript par une API sécurisée

Vous débutez totalement ? Commencez par la section « Mode débutant » de chaque atelier : elle explique où cliquer, quoi faire et comment vérifier votre résultat. Le code vient après les manipulations simples. Voir aussi le guide de prise en main →

Vous construisez une petite interface de consultation des réalisations sans exposer les brouillons ni autoriser des écritures anonymes.

Votre livrable professionnel

Route GET limitée aux contenus publiés ; validation des paramètres ; démonstration de permissions sur POST ; composant JavaScript fetch sans injection HTML ; plan de tests d’erreur.

Comment travailler ce module ?

  1. Lisez la notion et l’exemple.
  2. Reproduisez le code sur un WordPress de test, jamais sur le site d’un client.
  3. Vérifiez le résultat attendu et enregistrez une preuve.
  4. Validez votre étape avec le switch du panneau de progression.
  5. Terminez par le quiz noté, tout en bas de la page.

PARCOURS GUIDÉ

Cinq étapes pour produire un résultat concret

Cliquez sur une étape pour découvrir sa mission. Le bouton « Aller à cette étape dans le cours » ouvre directement sa procédure détaillée. Le switch en colonne de droite enregistre votre avancement.

ÉTAPE 01 / 05

Créer une route REST de lecture publique

Votre première route GET Les routes REST se déclarent sur rest_api_init . Une route publique doit renvoyer uniquement les contenus que le visiteur peut consulter. Exemple de route add_action(…

Action : lire la procédure, la reproduire, puis activer le switch après contrôle du résultat.

ÉTAPE 02 / 05

Ajouter validation d’arguments

Valider les paramètres et les limites Les API peuvent recevoir des valeurs mal formées : elles doivent être filtrées avant leur utilisation. Paramètre contrôlé ‘args’ => [
‘per_page’ => [
…

Action : lire la procédure, la reproduire, puis activer le switch après contrôle du résultat.

ÉTAPE 03 / 05

Contrôler les écritures et permissions

Protéger POST, PATCH et DELETE Pour modifier le contenu, une requête POST ne doit pas être ouverte à tous. Les permissions s’évaluent sur l’utilisateur réellement authentifié et parfois sur…

Action : lire la procédure, la reproduire, puis activer le switch après contrôle du résultat.

ÉTAPE 04 / 05

Afficher les résultats via fetch sécurisé

Afficher les données avec fetch sans XSS La réponse JSON ne doit pas être injectée comme HTML de confiance. Préférez textContent et la construction des éléments DOM. JavaScript d’affichage async…

Action : lire la procédure, la reproduire, puis activer le switch après contrôle du résultat.

ÉTAPE 05 / 05

Tester refus anonymes et cas d’erreur

Tests REST et tableau des erreurs Une API professionnelle s’évalue sur ses refus, pas seulement sur la réponse « heureuse ». Matrice à remplir GET public → 200 ; n’expose aucun…

Action : lire la procédure, la reproduire, puis activer le switch après contrôle du résultat.

COURS APPROFONDI & ATELIERS

Comprendre, coder et construire le site

Ces exemples sont volontairement progressifs. Les extraits de code s’exécutent dans des fichiers PHP d’un thème/plugin WordPress, pas directement dans le texte d’une page LiveCanvas.

Schéma de progression du module 6
Schéma pédagogique illustratif : ce n’est pas une capture réelle de votre écran WordPress.
ATELIER 01

Créer une route REST de lecture publique

↖ Revenir au parcours

MODE DÉBUTANT · ÉTAPE 01

Vous partez de zéro ? Suivez chaque clic.

L’API REST permet à un outil externe de lire certaines informations de WordPress. Avant d’écrire une route, observons les réponses existantes sans les modifier.

Où aller ?

Navigateur → https://votre-site.test/wp-json/ et /wp-json/wp/v2/posts.

Manipulation expliquée pas à pas
  1. 01
    Dans votre navigateur, ouvrez l’URL /wp-json/ de votre WordPress de test.
  2. 02
    Repérez le format JSON : des accolades, des champs et des valeurs.
  3. 03
    Ouvrez /wp-json/wp/v2/posts et observez les titres des articles publiés.
  4. 04
    Comparez l’accès à ces URL en navigation privée et en session administrateur.
  5. 05
    Dans votre carnet, notez que seules certaines données sont publiques et que les brouillons ne doivent pas être exposés.
Exemple à observer ou reproduire

{ "id": 12, "title": {"rendered": "Actualités de l’agence"}, "status": "publish" }

✓ Résultat attendu

Une réponse JSON apparaît et les brouillons ne sont pas visibles anonymement.

Si cela ne fonctionne pas

En cas d’erreur 404, vérifiez les permaliens et que l’API REST n’est pas bloquée par une extension de sécurité.

À retenir

API : interface d’échange de données. JSON : format texte structuré. GET : méthode de lecture.

Votre première route GET

Les routes REST se déclarent sur rest_api_init. Une route publique doit renvoyer uniquement les contenus que le visiteur peut consulter.

Exemple de route

add_action( 'rest_api_init', function (): void { register_rest_route( 'atelier/v1', '/projects', [ 'methods' => 'GET', 'permission_callback' => '__return_true', 'callback' => function () { return get_posts( [ 'post_type' => 'agency_project', 'post_status' => 'publish', 'numberposts' => 6, ] ); }, ] ); } );

Pas à pas

  1. Placez le code dans le plugin de semaine 5, pas dans une page LiveCanvas.
  2. Ouvrez /wp-json/atelier/v1/projects en navigation privée.
  3. Comparez avec trois projets publiés et deux brouillons.
  4. Vérifiez que les brouillons ne figurent pas dans les résultats.
  5. Remplacez l’envoi d’objets complets par un tableau contrôlé (id, title, url) dans la version professionnelle.

Attention : l’exemple commence simplement ; la version métier doit limiter précisément les champs exposés et contrôler tous les paramètres.

Point de contrôle 01

Le résultat est-il reproductible ? Gardez une preuve (capture ou extrait de code), puis validez l’interrupteur « Étape 01 » dans votre suivi.

ATELIER 02

Ajouter validation d’arguments

↖ Revenir au parcours

MODE DÉBUTANT · ÉTAPE 02

Vous partez de zéro ? Suivez chaque clic.

Une route personnalisée doit déclarer ses paramètres, types et limites afin d’éviter des requêtes excessives ou invalides.

Où aller ?

Plugin → rest_api_init/register_rest_route ; navigateur → /wp-json/agency/v1/projects?per_page=3.

Manipulation expliquée pas à pas
  1. 01
    Dans le plugin d’exercice, ajoutez un Hook rest_api_init.
  2. 02
    Enregistrez une route GET /agency/v1/projects dont permission_callback autorise la lecture publique uniquement pour les contenus publiés.
  3. 03
    Déclarez un argument per_page de type integer et limitez-le entre 1 et 24.
  4. 04
    Ouvrez l’URL avec ?per_page=3 puis essayez ?per_page=100 et observez le traitement de la limite.
  5. 05
    Documentez les champs retournés et évitez toute donnée privée.
Exemple à observer ou reproduire

register_rest_route('agency/v1','/projects', [ 'methods'=>'GET', 'permission_callback'=>'__return_true', 'callback'=>function() { return new WP_REST_Response(['message'=>'À remplacer par vos projets publiés'],200); } ]);

✓ Résultat attendu

La route répond avec des contenus publiés et refuse ou borne un paramètre invalide.

Si cela ne fonctionne pas

Une réponse publique ne doit jamais contenir de mot de passe, clé API, brouillon privé ou e-mail interne.

À retenir

Endpoint : adresse d’une route API. Validation : contrôle des paramètres reçus.

Conseil : Le code ci-dessus est une structure de route, pas encore une recherche de projets.

Valider les paramètres et les limites

Les API peuvent recevoir des valeurs mal formées : elles doivent être filtrées avant leur utilisation.

Paramètre contrôlé

'args' => [ 'per_page' => [ 'type' => 'integer', 'default' => 6, 'minimum' => 1, 'maximum' => 24, 'sanitize_callback' => 'absint', ], ],

Pas à pas

  1. Ajoutez args à la définition de la route de la première étape.
  2. Dans le callback, utilisez (int) $request['per_page'] comme nombre d’articles.
  3. Essayez ?per_page=3, puis ?per_page=0 et ?per_page=100.
  4. Vérifiez que les valeurs hors intervalle sont refusées (statut 400) plutôt qu’acceptées sans limite.
  5. Documentez les statuts HTTP 200, 400, 401/403.

Résultat

Le nombre maximal de contenus exposés est contrôlé côté serveur.

Point de contrôle 02

Le résultat est-il reproductible ? Gardez une preuve (capture ou extrait de code), puis validez l’interrupteur « Étape 02 » dans votre suivi.

ATELIER 03

Contrôler les écritures et permissions

↖ Revenir au parcours

MODE DÉBUTANT · ÉTAPE 03

Vous partez de zéro ? Suivez chaque clic.

La lecture publique et la modification de données n’ont pas les mêmes risques. Chaque action d’écriture doit vérifier l’identité et les capacités de l’utilisateur.

Où aller ?

Plugin → permissions de la route REST ; WordPress → Réalisations → Brouillons.

Manipulation expliquée pas à pas
  1. 01
    Dans le plugin de test, préparez une route POST pour créer un brouillon de projet.
  2. 02
    Ajoutez permission_callback qui vérifie current_user_can(‘edit_posts’) ou une capacité appropriée.
  3. 03
    Validez et assainissez le titre reçu avant wp_insert_post.
  4. 04
    Testez la route sans connexion : le serveur doit refuser la création.
  5. 05
    Testez ensuite avec un compte autorisé et un mécanisme d’authentification adapté à l’API ; vérifiez que le contenu créé est un brouillon.
Exemple à observer ou reproduire

// Exemple de contrôle : 'permission_callback' => function () { return current_user_can('edit_posts'); }

✓ Résultat attendu

Un anonyme ne peut pas créer de projet ; un utilisateur autorisé peut créer un brouillon contrôlé.

Si cela ne fonctionne pas

Attention : un nonce REST n’est pas un jeton d’autorisation autonome et n’établit pas la permission d’écrire. Il faut vérifier current_user_can().

À retenir

Authentification : qui est connecté ? Autorisation : que peut-il faire ? Validation : la donnée respecte-t-elle le format attendu ?

Protéger POST, PATCH et DELETE

Pour modifier le contenu, une requête POST ne doit pas être ouverte à tous. Les permissions s’évaluent sur l’utilisateur réellement authentifié et parfois sur l’objet ciblé.

Exemple de permissions pour un brouillon

'permission_callback' => function () { return current_user_can( 'edit_posts' ); }, 'callback' => function ( WP_REST_Request $request ) { $id = wp_insert_post( [ 'post_type' => 'agency_project', 'post_status' => 'draft', 'post_title' => sanitize_text_field( $request['title'] ), ], true ); return is_wp_error( $id ) ? $id : [ 'id' => $id ]; },

Pas à pas

  1. Créez une route séparée POST avec paramètres validés.
  2. Faites la requête en navigation privée : elle doit être refusée.
  3. Répétez avec un utilisateur autorisé et l’authentification prévue.
  4. Pour PATCH/DELETE, utilisez current_user_can( 'edit_post', $post_id ) ou delete_post selon l’opération.
  5. Vérifiez que l’ID demandé correspond bien au type agency_project.

À éviter : une permission basée seulement sur la présence d’un nonce ; un nonce ne prouve pas qu’on possède le droit de modifier l’objet.

Point de contrôle 03

Le résultat est-il reproductible ? Gardez une preuve (capture ou extrait de code), puis validez l’interrupteur « Étape 03 » dans votre suivi.

ATELIER 04

Afficher les résultats via fetch sécurisé

↖ Revenir au parcours

MODE DÉBUTANT · ÉTAPE 04

Vous partez de zéro ? Suivez chaque clic.

JavaScript peut consulter une API et mettre à jour un bloc de page sans rechargement. Les données renvoyées doivent être insérées de façon sûre.

Où aller ?

Thème/plugin → assets/js/projects.js ; navigateur → Inspecter → Console/Réseau.

Manipulation expliquée pas à pas
  1. 01
    Créez un fichier assets/js/projects.js dans le thème ou le plugin d’exercice.
  2. 02
    Ajoutez dans un template un conteneur vide <ul id= »agency-projects »></ul>.
  3. 03
    Dans le JS, utilisez fetch pour interroger une route GET publique.
  4. 04
    Créez des éléments <li> avec document.createElement ; utilisez textContent pour le texte venant de l’API.
  5. 05
    Ajoutez un message compréhensible si le réseau échoue ou si la liste est vide.
  6. 06
    Verifiez dans l’onglet Réseau les réponses API et l’absence d’erreur console.
Exemple à observer ou reproduire

fetch('/wp-json/wp/v2/posts?per_page=3') .then(r => { if (!r.ok) throw new Error('API indisponible'); return r.json(); }) .then(posts => { const list = document.querySelector('#agency-projects'); posts.forEach(post => { const li = document.createElement('li'); li.textContent = post.title.rendered; list.appendChild(li); }); }) .catch(() => console.warn('Chargement impossible'));

✓ Résultat attendu

Une liste de titres apparaît, et une erreur réseau affiche un message sans casser la page.

Si cela ne fonctionne pas

Évitez innerHTML pour afficher directement des champs JSON non fiables : une chaîne contenant des balises pourrait devenir du HTML actif.

À retenir

fetch : API JavaScript pour faire une requête HTTP. textContent : affectation de texte non interprété comme HTML.

Afficher les données avec fetch sans XSS

La réponse JSON ne doit pas être injectée comme HTML de confiance. Préférez textContent et la construction des éléments DOM.

JavaScript d’affichage

async function afficherProjets() { const res = await fetch('/wp-json/atelier/v1/projects'); if (!res.ok) throw new Error('Chargement impossible'); const projects = await res.json(); const list = document.querySelector('#projects-list'); list.replaceChildren(); projects.forEach(project => { const item = document.createElement('li'); item.textContent = project.post_title; list.append(item); }); } afficherProjets().catch(console.error);

Pas à pas

  1. Dans un template, ajoutez <ul id="projects-list"></ul>.
  2. Chargez le JavaScript par wp_enqueue_script, pas en collage de code non contrôlé.
  3. Vérifiez le contenu affiché et un état de chargement.
  4. Renommez un projet avec des signes < et > : il ne doit pas être interprété comme HTML.
  5. Simulez une erreur réseau et ajoutez un message lisible.

Résultat

Les données sont affichées sans innerHTML d’une valeur non fiable.

Point de contrôle 04

Le résultat est-il reproductible ? Gardez une preuve (capture ou extrait de code), puis validez l’interrupteur « Étape 04 » dans votre suivi.

ATELIER 05

Tester refus anonymes et cas d’erreur

↖ Revenir au parcours

MODE DÉBUTANT · ÉTAPE 05

Vous partez de zéro ? Suivez chaque clic.

Une API doit être testée avec plusieurs profils d’accès et plusieurs types de réponses, pas seulement avec un administrateur déjà connecté.

Où aller ?

Outils de développement, Postman/équivalent, ou interface de test des requêtes API.

Manipulation expliquée pas à pas
  1. 01
    Dressez un tableau des scénarios GET anonyme, POST anonyme, POST autorisé, mauvaise valeur per_page et ressource inexistante.
  2. 02
    Exécutez les requêtes avec les outils de votre choix depuis l’environnement de test.
  3. 03
    Notez le code HTTP obtenu (200, 400, 401, 403, 404 selon le scénario et le mécanisme d’authentification).
  4. 04
    Vérifiez que les brouillons ne figurent pas dans une route de lecture publique.
  5. 05
    Corrigez les problèmes de permissions puis refaites le même jeu de tests.

Exemple concret : Livrable : tableau « scénario / rôle / méthode / résultat attendu / résultat observé ».

✓ Résultat attendu

Une matrice prouve les refus et autorisations attendus ; aucun brouillon n’est renvoyé publiquement.

Si cela ne fonctionne pas

Un code HTTP 200 ne signifie pas que la réponse est sûre : vérifiez aussi le contenu retourné.

À retenir

HTTP 401 : authentification requise ; 403 : accès interdit ; 400 : requête invalide.

Tests REST et tableau des erreurs

Une API professionnelle s’évalue sur ses refus, pas seulement sur la réponse « heureuse ».

Matrice à remplir

GET public → 200 ; n'expose aucun brouillon GET per_page=100 → 400 ; argument refusé POST anonyme → 401/403 ; contenu non créé POST auteur autorisé → 200/201 ; brouillon créé PATCH autre auteur → 403 ; modification refusée ID inexistant → 404 ; message neutre

Pas à pas

  1. Reproduisez les six cas via un client REST (navigateur, Postman ou autre).
  2. Conservez requête, code HTTP et extrait de réponse pour chaque cas.
  3. Notez si le test a besoin d’une session ou d’un nonce REST.
  4. Vérifiez qu’aucune erreur serveur 500 n’est déclenchée par une entrée invalide.
  5. Après correction, relancez tous les cas, y compris ceux qui fonctionnaient déjà.

Livrable

Une API de démonstration et un tableau de recette montrant les refus d’accès attendus.

Point de contrôle 05

Le résultat est-il reproductible ? Gardez une preuve (capture ou extrait de code), puis validez l’interrupteur « Étape 05 » dans votre suivi.

SOURCES & SUPPORTS

Ressources du module

Documentation officielle : Consulter la référence WordPress ↗. Vidéos : ajoutez des tutoriels enregistrés et vérifiés dans LiveCanvas ; aucune vidéo factice n’est présentée comme un cours existant.

Note pédagogique — Les PDF sont des supports transversaux. Les extraits de code et procédures enrichies de cette page font partie de la V2.3. Les corrigés détaillés des quiz apparaissent seulement après soumission du questionnaire.

FIN DU MODULE · ÉVALUATION

Vérifiez vos connaissances

Répondez aux cinq questions. Après correction, découvrez votre note sur 20, le nombre d’erreurs et l’explication de chaque réponse. Quatre réponses correctes sur cinq sont nécessaires pour valider le nouveau quiz.

1. Sur quel Hook enregistrer les routes REST ?
2. Une route d’écriture métier peut-elle être ouverte à tous ?
3. Quel outil JS peut lire une API REST ?
4. Pour afficher une valeur JSON utilisateur sans l’interpréter comme du HTML, quel usage est préférable ?
5. Quel statut de publication doit être filtré pour une API publique listant des projets visibles ?

Connexion nécessaire pour enregistrer la note et les corrections.