Dans ce cours on va étudier le bloc « relationnel » qui permet de sélectionner une publication via un moteur de recherche, afin d’afficher le résumé d’une publication, avec l’image, l’auteur et la catégorie. On verra également comment construire le composant de recherche.
Cours Premium
Ce cours est hyper intéressant !
Mais il est réservé aux détenteurs d’une offre premium.
Envie de nous rejoindre ?
Déjà membre ? Connexion
Yoan
Le 23 avril 2024
Salut, merci beaucoup pour tes cours !
J’ai suivi la formation en entière, elle m’a beaucoup aidée.
J’ai un problème qui subsiste et qui est bien illustré dans ce cours.
Je comprend bien que l’exemple de ce cours sert à illustrer un fonctionnement, mais, en pratique, faire trois requêtes pour récupérer le post, l’auteur, et l’image, c’est dramatique.
Et justement, mon problème est que je ne peux pas me résoudre à faire des requêtes AJAX à chaque bloc qui composent la page, car je me dis que si tous les développeurs font ça, on va tous se retrouver avec des pages qui demandent des dixaines de requêtes pour être chargées une seule fois complètement.
Or avec WooCommerce, lorsque l’on charge la page « Panier », on voit que les blocs chargent puis s’affichent. Ils affichent des données stockées dans la session du visiteur ou en base de données, donc coté serveur. Mais en ouvrant la console du navigateur on voit qu’aucune requête AJAX n’a été faite. Dans le code source de WooCommerce, aucun fichier PHP n’affiche le contenu du panier. Et dans le code source de la page, on ne voit aucune variable qui aurait pu être passée du PHP vers JS (via wp_add_inline_script par exemple).
Comment ça marche ?
Comment afficher des données de la base de données dans un Block, sans les afficher directement en PHP, sans faire de requête AJAX, et sans passer les variables de PHP vers JS avec wp_add_inline_script ?
Maxime BJ
Le 23 avril 2024
Salut Yoan ! C’est une très bonne réflexion de ta part.
Lorsqu’on fait une application web en React. On fait énormément d’appels API en réalité. Bien sûr, ils sont mis en cache et dédoublonnés. Mais en général une app charge ses composants à vide, et ceux-ci vont aller chercher la donnée en Ajax vers le serveur. Ce n’est donc pas un mal. Une requête API optimisée mettent moins de 50 ms à faire l’aller retour, et le résultat renvoyé est du JSON, ce qui est léger.
Bien entendu, WordPress ne gère pas son templating en full JS et son API n’est pas la plus optimale (car ça charge le coeur de WP à chaque fois), et dans le retour on envoie du HTML au lieu du JSON. Malgré tout, ça reste encore largement correct. Si tu as énormément d’appels Ajax, je recommande de passer sur du headless : WordPress ne fonctionne que comme un backend, et le front-end est fait dans une autre techno (React, via Next.js ou Gatsby par exemple).
Cela dit, il existe tout de même plusieurs solutions :
– La première, c’est de créer une route custom sur l’API de WP qui te permettrait de récupérer en un appel toutes les données dont tu as besoin. Côté backend, tu pourrais faire plusieurs WP Query pour récupérer plein d’infos et les regrouper dans un tableau, que tu renverrais en JSON, ou alors tu renvoies carrément un template HTML tout prêt.
– La seconde solution, c’est d’installer GraphQL via le plugin WordPress du même nom. GraphQL ne possède qu’une seule route, et propose un langage de requête (Query Language : QL) qui te permet de piocher uniquement les informations dont tu as besoins en front. Par exemple le titre d’un article, son contenu, le prénom de l’auteur et l’image à la une. Toutes les autrs informations comme la catégorie, la date de publication… seront ignorées.
Il n’y a pas de meilleure solution : ça dépendra, comme toujours de ta problématique et du contexte de ton site. Mais tu as désormais pleins de solutions à ta disposition !
Pour WooCommerce, le panier est stocké dans le navigateur du client, c’est la commande uniquement qui est stockée en base, lorsqu’elle est validée. C’est mieux ainsi, et d’ailleurs un peu obligatoire pour des raisons de respect du RGPD.
Si tu as besoin d’afficher des données dans un bloc, il suffit de les récupérer au moment de la génération du template si ce sont des données dynamiques comme on le voit dans ce cours. Ainsi, lorsque la page est envoyée au client, toutes les données sont déjà générées.
Yoan
Le 24 avril 2024
Merci beaucoup pour ta réponse 🙂
Pardon j’aurais dû préciser que je suis auteur de plugins, c’est un cas peu spécial car le plugin sera installé dans toute sorte d’environnement. Je dois prendre en compte toutes les configurations matérielles et considérer que 250ms est un bon temps de réponse et qu’il peut aller jusqu’à 1 seconde par requête, et surtout, que je ne suis pas le seul plugin installé et que chacun va potentiellement faire sa requête.
Je vais priviligier la solution de faire passer les variables PHP à JS avec wp_add_inline_script.
En fait on avait tous les deux tort, WooCommerce stocke bien le panier en base de données (anonymement) dans la table wp_woocommerce_session, et il le passe bien de PHP à JS avec wp_add_inline_script dans woocommerce\src\Blocks\Assets\AssetDataRegistry.php ligne 395.
Il encode les données avant de les imprimer sur la page, c’est pour ça que je ne les avais pas vu. Et par curiosité j’ai fait un petit print_r pour voir ce qu’il imprime sur la page… Un array de plus de 7000 lignes… Ben oui, on (les plugins) a besoin de la base de données et on ne peut pas multiplier les requêtes, alors on imprime la base de données sur la page…
Désolé, je sais que tu es enthousiaste de cette techno, mais moi elle me désespère ^^’. Sans parler du mur que représente son apprentissage, alors que le succès de WP est avant tout dû à son accessibilité, qui a permis la multiplication de plugins. Qu’aurait été WordPress sans ses plugins ? J’en ai parlé à Automattic sur un article lunaire où ils expliquent « Tu vois ce que tu pouvais faire avec 8 lignes de code avant, eh bien maintenant, il faut que tu apprenne deux languages (ESNext et ReactJS), que tu crées un environnement de développement, que tu fasses des lignes de commande, que tu compiles ton code, que …. » Stooop, je veux juste afficher « Hello World $php_variable ». Eh ben c’est pareil. Leur réponse est encourageante « it’s an unintended reality that extensibility is now harder, and we’re trying to fix that. », mais le mal est fait et on ne reviendra pas en arrière.
Sur Google, les nouveaux tutos sortis en 2024 apprennent aux gens comment utiliser les anciens hooks PHP. Sur Stackoverflow, il n’y a que des questions sans réponses concernant l’extensibilité des blocks. Sur le repo, il y a 469 plugins qui utilisent les blocks… sur 59 569. Gutenberg est sorti il y a 6 ans. Aujourd’hui Gutenberg peut autant redresser la barre que faire couler WordPress, mais moi qui bosse dans la cale, je peux dire qu’il y a de la flotte.
Ta formation est d’autant plus exceptionnelle dans ce contexte, merci encore à toi.
Maxime BJ
Le 24 avril 2024
Merci pour cette réponse très détaillée et très intéressante.
Mais ne te méprends pas, j’aime bien WordPress mais j’admet que niveau tech et code, c’est un vrai carnage.
Je te rejoins sur le souci de temporalité du moteur de recherche : on va trouver 50 résultats dispatchés dans le temps et qui se contredisent tous.
C’est complexe de faire du React sur WP parce que la communauté n’a pas réagit assez vite.
Je fais également du Next.JS et même si ces technos sont plus complexes que du PHP classique, c’est très simple de mettre en place un environnement de travail et faire des miracles avec. Alors qu’avec WordPress, c’est chiant.
En tant que développeur de plugin, tu ne peux même pas prendre de liberté du coup sur la façon de faire en effet ! Bref, il y a du mieux quand même peu à peu, notamment avec l’arrivée de Gutenberg. Mais c’est pas encore ça côté front.
Yoan
Le 24 avril 2024
Ah ah, alors on est d’accord !
Juste pour la discussion,
Ce qui me rend fou, c’est que WordPress n’ait pas analysé ce qui faisait son succès pour poursuivre son développement dans la même lignée. Il n’a pas fait évoluer son éditeur progressivement, par itération, dans le respect de ses utilisateurs et de ses développeurs, et de ses propres principes d’ailleurs. Au lieu de ça, il a développé un autre éditeur à part qui n’a rien en commun avec WordPress, et il l’a imposé à tous en disant « C’est l’avenir ! ». Sauf que le succès ne se décide pas.
Maxime BJ
Le 24 avril 2024
Alors la nouvelle équipe qui a bossé sur le full site editing / Gutenberg a fait un boulot admirable, tout à base de JS et React. C’est propre. Mais c’est vrai que comme ils ne voulaient pas tout chambouler non plus, ils ont tout basé sur le système en place pour la base de données. Du coup c’est pas foufou. Après Gutenberg est là depuis 2018 au final. D’abord comme éditeur de contenu, et là le Full Site Editing est arrivé ensuite progressivement.
Il y a un moment où ils sont obligés de bousculer un peu les habitudes car sinon personne ne changerait. Mais cela dit, la création de sites en templates classique reste toujours d’actualité et ce pour un bon moment. Par contre en tant que dev de plugin, ce qui est très chiant c’est de devoir s’adapter aux deux mondes.