L’API REST de WordPress permet à tout utilisateur (webmaster) de s’interfacer avec les données publiques ou privées d’un site réalisé avec le CMS. Nous allons voir une manière (il en existe plusieurs) pour se connecter à l’API REST de WordPress avec PHP, tout en utilisant de l’URL Rewriting pour obtenir des URL jolies comme tout, dans un environnement externe à WordPress. Sous entendu, nous allons appeler les données d’un site WordPress pour des pages PHP indépendantes du CMS.
Non pas que je ne veuille fournir davantage d’informations sur ce qu’est l’API REST de WordPress, ou même sur des bases de PHP, l’idée est ici d’obtenir quelques exemples de codes clés en main pour avancer plus rapidement, et non de faire de la littérature (par ailleurs très bien réalisée sur d’autres blogs). Bien entendu, comme pour tout ce qui touche au développement, chacun aura loisir de personnaliser et réadapter les exemples de codes pour lui-même. Ici encore, j’ai fait le choix d’un code en PHP procédural qui pourra parler à tout le monde, tout en utilisant des fonctions pour rester coller proche de l’esprit “objet” de la POO (chaque fonction pouvant être vue comme un objet ou une méthode, il suffirait juste de réadapter un peu l’écriture).
Nous allons étudier plusieurs points fondamentaux pour s’amuser un minimum avec l’API :
Dans l’exemple que je vais prendre, la structure du site indépendant est à la racine, et un répertoire “wordpress” est à l’intérieur pour recueillir le CMS. Personne n’accèdera au dossier du WordPress, seul le site indépendant à la racine pourra l’utiliser et le back-office restera accessible (c’est mieux si on veut gérer les données ^^). Tenez bien compte de cette structure car elle influence toute la partie sur le .htaccess et la réécriture d’URL (même dans les fonctions PHP), donc il faudra réadapter un peu si vous souhaitez vraiment séparer le WordPress (mais ce n’est pas forcément recommandé).
Vous vous demandez peut-être pourquoi il est intéressant d’utiliser l’API REST quand on a déjà un site WordPress sous la main ? Et bien il existe plusieurs raisons de faire des appels dans des sites web indépendants, et je vais en citer au moins deux parmi elles, qui me semblent suffisamment parlantes :
Le seul inconvénient provient de la perte d’utilisation de certains types de plugins pour le front office. En effet, si vous utilisez des plugins d’accordion ou de sliders par exemple, il vous manquera certainement les CSS et JS correspondants, offrant un rendu inutilisable. L’astuce consiste alors à récupérer les fichiers utiles, mais cela ne facilite pas les choses. Souvent, c’est directement dans le site indépendant que l’on gère ces types de plugins JS/jQuery, etc.
Pour information, vous pouvez consulter l’API REST en tapant “/wp-json” à la fin de l’URL de base d’un site WordPress. Le résultat ressemble à une liste de données, dont celles qui nous importent le plus sont les routes, à savoir les chemins d’accès à chaque type de donnée disponibles (pages, posts, users, medias…).
API REST de WordPress en PHP
Vous verrez de temps l’usage de la fonction getMenuUrl(), cette dernière est utile uniquement pour réécrire les URL avec les formes “page/…” et “article/…” directement, sans avoir à intégrer des URL absolues partout dans les pages (un des défauts de WordPress, mais pas simple à éviter dans les faits). Voici la fonction si nécessaire, qui fonctionne pour l’exemple de cet article.
Il existe une multitude de manière de se connecter à l’API REST de WordPress avec PHP, soit avec cURL, soit avec file_get_contents() notamment. J’ai opté pour la seconde solution ici, en apportant des paramètres complémentaires utiles pour la structure du site en exemple.
Il s’agit d’une fonction get() prenant 1 paramètre obligatoire (le chemin vers la ressource de l’API REST) et 3 paramètres optionnels :
Comme vous le voyez, tout est prévu dans la fonction pour retourner une erreur si la route utilisée pour l’API est inaccessible (retourne une erreur grâce au try/catch), etc. Il ne reste donc plus qu’à exploiter la fonction… 🙂
Voici un exemple simple qui permet de récupérer la liste des articles de WordPress avec l’API REST et PHP. Le code HTML n’est valable qu’à titre d’exemple, vous pouvez faire ce que vous voulez.
Cet exemple va afficher les un sous les autres les articles de la catégorie “non-classé” de WordPress, avec le titre, la date et l’extrait de l’article. Pour voir d’autres types de données récupérables, l’idéal est de faire un var_dump($posts) ou print_r($posts) pour avoir la liste des appels possibles.
Contrairement à la base de données de WordPress, il ne faut pas appeler les données directement par le nom des colonnes habituelles. Par exemple, le titre se récupère dans la colonne “post_title” dans la BDD, mais avec l’API REST, il faut l’afficher avec $instance->title->rendered ($instance varie selon l’appel que vous avez effectué). Il faut donc être vigilant aux différentes possibilités, mais tout a été prévu. Ainsi, vous pouvez éviter d’utiliser le “guid” de WordPress (URL non réécrite) en le remplaçant par le “link”, comme dans l’exemple ci-dessus, et ainsi profiter d’une URL propre, nettoyée dans l’exemple par la fonction getMenuUrl().
Ensuite, quand on clique sur un lien parmi la liste d’articles, l’idéal est d’afficher le contenu de l’article, etc. Dans notre exemple, nous allons récupérer les données grâce au slug de l’article (capté via $post->link et la réécriture d’URL proposée en fin d’article). Ainsi, dans le fichier articles.php de l’exemple, nous avons d’un côté la liste des articles, et dans un autre bloc le contenu d’un article donné, repris par un code comme celui-ci.
Il ne s’agit que d’un exemple, mais il vous donne une idée de la manière de récupérer des données d’auteur d’un article, etc. Ici, il y a également la gestion du paramètre “slug” pour cibler un article par le slug récupéré via l’URL rewriting. Cela pourrait aussi fonctionner avec un ID si besoin, avec le paramètre “id” bien entendu.
Pour récupérer le contenu des pages, c’est globalement le même fonctionnement que pour les articles, si ce n’est que la route change. Je ne vous remontre donc pas tout, mais voici comment récupérer les données d’une page captée par son slug, dans le même esprit que ce qui a été vu précédemment.
Il peut être intéressant de récupérer tout un menu complet avec l’API REST, mais WordPress ne l’a pas prévu nativement. Vous avez donc le choix de créer les routes (endpoints) vous-mêmes avec register_rest_routes() et des callbacks, ou en installant un plugin clé en main. Dans l’exemple, c’est l’extension WP REST API V2 Menus de Claudio La Barbera qui sert de base, et qui a ajouté plusieurs endpoints utiles.
Il est possible de récupérer tous les menus ou tous les emplacements de menu, mais l’usage le plus courant est de cibler un menu en particulier. Dans le cas, la route à utiliser dans la fonction get() est “/menus/v1/menus/SLUG_MENU”.
Ci-dessous, le code permet de récupérer tous les items d’un menu appelé “menu” (comme c’est original ^^). Vous noterez qu’il est possible de récupérer la cible du lien, voire d’autres paramètres si vous en avez besoin.
Nous n’avons pas fait le tour de toutes les possibilités, mais vous devez déjà avoir un aperçu suffisant pour vous lancer. Peut-être que j’écrirais d’autres articles plus poussés sur le sujet si les demandes affluent (et si le temps me le permet), mais rien n’est encore sûr. Avant de se quitter, voici comment gérer la réécriture d’URL pour sécuriser davantage le WordPress, avec une astuce en prime à la fin…
Dans un premier temps, nous allons traiter de la réécriture d’URL à visée esthétique. Ainsi, dans notre site “fait main”, nous aurons des URL avec les slugs de WordPress, ce sera bien plus joli que des adresses avec des query strings comme ?id=12 ou ?page=25 en fin d’URL (sans parler des risques pour la sécurité quand rien n’est prévu pour en amont).
Dans un fichier .htaccess, placez le code suivant, qui permet de gérer l’affichage des pages, des articles et même des médias, comme je vais vous le montrer par la suite :
En complement, la sécurité du WordPress utilisé en arrière-plan est nécessaire pour se protéger complètement. Nous avons observé ci-dessus que les médias sont également rediriger, cela présuppose que l’URL des médias de WordPress est modifiée à la volée lorsque l’on affiche les contenus dans le site. Pour ce faire, j’ai créé une fonction getCleanedContent() qui permet à la fois de supprimer le chemin des médias, mais aussi de nettoyer les classes de WordPress inutiles (et qui laissent des empreintes gênantes…). Sachez toutefois que l’astuce ne peut fonctionner que si vous ajouter tous les médias de WordPress dans le dossier upload, et non dans des sous-répertoires classés par date (il faut décocher le paramètre dans Réglages->Médias).
Il suffit d’ajouter cette fonction PHP lors de l’appel des contenus via l’API REST de WordPress, et ainsi les médias seront nettoyés, comme dans la capture suivante. Plus de classes ni de chemin vers le dossier “uploads” de WordPress, tout est géré discrètement par la réécriture d’URL.
API REST de WordPress en PHP
D’autres aspects peuvent être ajoutés pour sécuriser encore davantage le WordPress caché. L’idéal est de modifier le fichier .htaccess du WordPress en lui-même (différent de celui du site que nous avons créé précédemment) pour bloquer l’accès au front office du CMS. Voici le code à ajouter, qui permet de voir le dossier wp-admin, et donc d’administrer le site, sans que le reste ne soit accessible.
Souvent, les webmasters utilisent le drapeau [R=403] affichant un accès interdit, mais cela présuppose qu’il existe un WordPress. Je trouve plus malin d’utiliser une erreur 404 en retour pour sous-entendre qu’aucun WordPress n’existe. Il suffit d’ajouter ce code sous les lignes écrites par WordPress dans le fichier .htaccess à la racine de l’outil.
Voilà, vous savez désormais comment utiliser les larges bases de l’API REST de WordPress avec PHP. Certes, il reste encore une multitude de possibilités, non présentées ici, mais le principe reste globalement toujours le même. Vous pouvez créer vos propres routes pour l’API, notamment si vous créez des custom post types par exemple, ou encore ajouter des surcouches d’authentification pour protéger les accès à l’API (si cela est utile car tout est masqué dans l’exemple, difficile de savoir qu’un WordPress est derrière…). Presque tout est possible, et cela rend l’intérêt très fort, mixant ainsi avec la souplesse d’un WordPress, utilisé en arrière-plan, et la souplesse d’un site “fait main”, notamment pour booster le SEO en retirant le superflu.




Auteur : Alexandra Martin / Mathieu Chartier
Editeur : Eyrolles
Prix : 32,00 € (345 pages)
Auteur : Alexandra Martin / Mathieu Chartier
Editeur : Eyrolles
Prix : 32,00 € (570 pages)
Auteur : Alexandra Martin / Mathieu Chartier
Editeur : Eyrolles
Prix : 29,90 € (522 pages)
Auteur : Mathieu Chartier
Editeur : First Interactive
Prix : 19,90 € (411 pages)
Auteur : Mathieu Chartier
Editeur : First Interactive
Prix : 29,90 € (622 pages)
Télécharger “SwipeMenu.zip”SwipeMenu.zip – Téléchargé 18067 fois – 52 Ko
Télécharger “Spider Simulator PHP”spider-simulator.zip – Téléchargé 17480 fois – 2 Ko
Télécharger “ReadingIndicator 1.0”readingIndicator-1.0.zip – Téléchargé 15917 fois – 7 Ko
Télécharger “Parseur Facebook”parser-facebook.zip – Téléchargé 17316 fois – 3 Ko
Télécharger “Pack complet – moteur de recherche PHP 5.5 – PHP 7”moteurPHP5.5.zip – Téléchargé 34883 fois – 171 Ko
Ce blog est le résultat de plusieurs années de travail mais il ne fait pas manger son homme. Découvrez l’agence web et l’organisme de formation géré par Mathieu Chartier et n’hésitez pas à prendre contact pour suivre des formations personnalisées.
Tous droits réservés © Blog Internet-Formation 2009 – 2022

source

Catégorisé:

Étiqueté dans :