Leonardo Losoviz est un développeur et écrivain indépendant, dont la mission est d'intégrer des paradigmes innovants (PHP sans serveur, composants côté serveur, GraphQL)… Plus d'informations sur Leonardo …
Le terme COPE («Créer une fois, publier partout») est une méthodologie permettant de publier notre contenu sur différents supports (site Web, site AMP, courrier électronique, applications, etc.) en disposant d'une source unique de vérité. pour tous. Voyons maintenant comment implémenter COPE avec WordPress.
COPE est une stratégie visant à réduire la quantité de travail nécessaire pour publier notre contenu sur différents supports, tels que des sites Web, des emails, des applications, etc. Lancé pour la première fois par NPR il remplit son objectif en établissant une source unique de vérité pour un contenu utilisable pour tous les supports.
Avoir un contenu qui fonctionne partout n'est pas une tâche aisée, car chacun moyen aura ses propres exigences. Par exemple, alors que HTML est valide pour l'impression de contenu pour le Web, cette langue n'est pas valide pour une application iOS / Android. De même, nous pouvons ajouter des classes à notre code HTML pour le Web, mais celles-ci doivent être converties en styles pour le courrier électronique.
La solution à ce problème est de séparer le formulaire du contenu: la présentation et la signification du contenu doivent être découplées, et seule la signification est utilisée comme source unique de vérité. La présentation peut ensuite être ajoutée dans une autre couche (spécifique au support sélectionné).
Par exemple, étant donné le code HTML suivant, le est une balise HTML qui s'applique principalement au Web et à l'attribut class = "align-center" est présentation (placer un élément «au centre» est logique pour un support basé sur un écran, mais pas pour un support basé sur l’audio tel que Amazon Alexa):
Hello world !
Par conséquent, ce contenu ne peut pas être utilisé comme une source unique de vérité et doit être converti en un format séparant le sens de la présentation, tel que le code JSON suivant:
{
contenu: "Bonjour tout le monde!",
placement: "centre",
type: "paragraphe"
}
Ce morceau de code peut être utilisé comme source unique de vérité pour le contenu, car il permet de recréer à nouveau le code HTML à utiliser pour le Web et de procurer un format approprié pour d'autres supports.
Pourquoi WordPress [A19659002] WordPress est idéal pour mettre en œuvre la stratégie COPE pour plusieurs raisons:
Il est polyvalent. Le modèle de base de données WordPress ne définit pas un modèle de contenu fixe et rigide. au contraire, il a été créé pour la polyvalence, permettant de créer des modèles de contenu variés à l’aide de méta-champs, qui permettent de stocker des données supplémentaires pour quatre entités différentes: les posts et types de posts personnalisés, les utilisateurs, les commentaires et les taxonomies ( balises et catégories).
Il est puissant. WordPress se présente comme un CMS (système de gestion de contenu) et son écosystème de plug-ins permet d'ajouter facilement de nouvelles fonctionnalités.
Il est répandu. Il est estimé qu'un tiers des sites Web fonctionnent sous WordPress. Ensuite, un nombre considérable de personnes travaillant sur le Web connaissent et peuvent utiliser, par exemple WordPress. Non seulement les développeurs, mais aussi les blogueurs, les vendeurs, le personnel de marketing, etc. Ensuite, de nombreuses parties prenantes, quels que soient leurs antécédents techniques, seront en mesure de produire le contenu qui constitue l'unique source de vérité.
Il est sans tête. L'absence de tête est la capacité de découpler le contenu de la couche de présentation. , et c’est une caractéristique fondamentale de la mise en oeuvre de COPE (pour pouvoir transmettre des données à des supports différents).
Depuis l’intégration de l’API WP REST API dans le noyau à partir de la version 4.7, et plus nettement depuis la version 4.7. Lors du lancement de Gutenberg dans la version 5.0 (pour laquelle de nombreux points de terminaison de l'API REST devaient être implémentés), WordPress peut être considéré comme un CMS sans tête, car la plupart du contenu WordPress est accessible via une API REST par n'importe quelle application construite sur n'importe quelle pile.
En outre, le WPGraphQL récemment créé, intègre WordPress et GraphQL, ce qui permet d’alimenter le contenu de WordPress dans n’importe quelle application utilisant cette API de plus en plus populaire. Enfin, mon propre projet PoP a récemment ajouté une implémentation d'une API pour WordPress qui permet d'exporter les données WordPress aux formats natifs REST, GraphQL ou PoP.
. Gutenberg un éditeur basé sur des blocs qui facilite grandement la mise en œuvre de COPE car il est basé sur le concept de blocs (comme expliqué dans les sections ci-dessous).
Blobs contre blocs permettant de représenter des informations
Un blob est une seule unité d'informations stockée dans la base de données. Par exemple, l'écriture de l'article de blog ci-dessous sur un CMS qui stocke des informations sur des blobs stockera le contenu de l'article de blog sur une seule entrée de base de données contenant ce même contenu:
Regardez ce merveilleux tango:
performance
Comme on peut le comprendre, les informations importantes de cet article de blog (telles que le contenu du paragraphe, l’URL, les dimensions et les attributs de la vidéo Youtube) ne sont pas facilement accessibles: Si nous voulons Pour récupérer l'un d'eux par eux-mêmes, nous devons analyser le code HTML pour les extraire – ce qui est loin d'être une solution idéale.
Les blocs agissent différemment. En représentant les informations sous forme de liste de blocs, nous pouvons stocker le contenu de manière plus sémantique et plus accessible. Chaque bloc véhicule son propre contenu et ses propres propriétés, qui peuvent dépendre de son type (par exemple, s'agit-il d'un paragraphe ou d'une vidéo?).
Par exemple, le code HTML ci-dessus pourrait être représenté sous la forme d'une liste de blocs comme ceci:
Grâce à cette manière de représenter l'information, nous pouvons facilement utiliser n'importe quelle donnée et l'adapter au support spécifique sur lequel elle doit être affichée. Par exemple, si nous voulons extraire toutes les vidéos de l'article de blog pour les afficher sur un système de divertissement automobile, nous pouvons simplement itérer tous les blocs d'informations, sélectionnez ceux avec type = "embed" et provider = "Youtube" et extrayez l'URL de ceux-ci. De même, si nous voulons montrer la vidéo sur une Apple Watch, nous ne devons pas nous soucier de ses dimensions. Nous pouvons donc ignorer les attributs width et height de manière simple.
Comment Gutenberg implémente les blocs
Avant la version 5.0 de WordPress, WordPress utilisait des blobs pour stocker le contenu d'un message dans la base de données. À partir de la version 5.0, WordPress est fourni avec Gutenberg, un éditeur basé sur des blocs, ce qui permet de mieux traiter le contenu mentionné ci-dessus, ce qui représente une avancée décisive dans la mise en œuvre de COPE. Malheureusement, Gutenberg n'a pas été conçu pour ce cas d'utilisation spécifique et sa représentation des informations est différente de celle qui vient d'être décrite pour les blocs, ce qui entraîne plusieurs inconvénients que nous devrons traiter.
Voyons tout d'abord. comment le billet de blog décrit ci-dessus est sauvegardé via Gutenberg:
Regardez ce merveilleux tango:
https://www.youtube.com/embed/sxm3Xyutc1s
Un spectacle de tango exquis
À partir de ce morceau de code, nous pouvons formuler les observations suivantes:
Les blocs sont sauvegardés tous ensemble dans la même entrée de base de données
Le code ci-dessus comprend deux blocs:
Regardez ce merveilleux tango:
https://www.youtube.com/embed/sxm3Xyutc1s
Un spectacle de tango exquis
À l'exception des blocs globaux (également appelés «réutilisables»), qui ont leur propre entrée dans la base de données et peuvent être référencés directement par leur ID, tous les blocs sont sauvegardés ensemble dans l'entrée du billet de blog dans le tableau wp_posts .
Ainsi, pour récupérer les informations d’un bloc spécifique, nous devons d’abord analyser le contenu et isoler tous les blocs les uns des autres. WordPress fournit commodément la fonction parse_blocks ($ content) pour ce faire. Cette fonction reçoit une chaîne contenant le contenu de la publication de blog (au format HTML) et renvoie un objet JSON contenant les données de tous les blocs contenus.
Les attributs et types de blocs sont transmis au moyen de commentaires HTML
Chaque bloc est délimité par un balise de départ et une balise de fin qui (sous forme de commentaires HTML) garantissent que cette information ne sera pas visible lors de son affichage sur un site Web. Toutefois, nous ne pouvons pas afficher la publication de blog directement sur un autre support, car le commentaire HTML peut être visible et apparaître sous forme de contenu tronqué. Ce n'est pas un problème cependant, car après avoir analysé le contenu à l'aide de la fonction parse_blocks ($ content) les commentaires HTML sont supprimés et nous pouvons utiliser directement les données de bloc sous forme d'objet JSON.
Contain HTML
Le bloc de paragraphe a "
Regardez ce merveilleux tango:
" dans son contenu, au lieu de "Regardez ce merveilleux tango:" . Il contient donc du code HTML (balises et
) qui n’est pas utile pour d’autres supports, et doit donc être supprimé, par exemple via la fonction PHP strip_tags ($ content) . [19659005] Lors du dépouillement des balises, nous pouvons conserver les balises HTML qui transmettent explicitement des informations sémantiques, telles que les balises et (au lieu de leurs homologues et qui s’appliquent uniquement à un support basé sur un écran), et supprimez toutes les autres balises. En effet, il est fort probable que les balises sémantiques puissent également être interprétées correctement sur d'autres supports (par exemple, Amazon Alexa peut reconnaître les balises et et modifier sa voix et son intonation en conséquence lors de la lecture d'un texte). Pour ce faire, nous appelons la fonction strip_tags avec un deuxième paramètre contenant les balises autorisées et nous le plaçons dans une fonction d'habillage par souci de commodité:
La légende de la vidéo est enregistrée dans le code HTML et non pas comme un attribut
Comme on peut le voir dans le bloc vidéo Youtube, la légende "Une performance de tango exquise" est stockée dans le code HTML ( entouré par la balise ), mais pas à l'intérieur de l'objet d'attributs codés JSON. En conséquence, pour extraire la légende, nous devrons analyser le contenu du bloc, par exemple à l'aide d'une expression régulière:
Il s'agit d'un obstacle à surmonter pour extraire toutes les métadonnées d'un bloc de Gutenberg. Cela se produit sur plusieurs blocs; Etant donné que toutes les métadonnées ne sont pas enregistrées en tant qu'attributs, nous devons d'abord identifier quelles sont ces métadonnées, puis analyser le contenu HTML pour les extraire bloc par bloc et pièce par pièce.
En ce qui concerne COPE, cela représente une chance perdue d’avoir une solution vraiment optimale. On pourrait soutenir que l’option alternative n’est pas non plus idéale, car elle dupliquerait des informations en les stockant à la fois dans le code HTML et en tant qu’attribut, ce qui constituerait une violation de DRY ( D on't R epeat Y nous-mêmes) principe. Cependant, cette violation a déjà eu lieu: par exemple, l'attribut className contient la valeur "wp-embed-aspect-16-9 le rapport d'aspect wp" qui est imprimé également dans le contenu, sous attribut HTML classe .
