imath

J’ai quitté 2017 en vous parlant de contributions et de Gutenberg. Je démarre 2018, en vous souhaitant une excellente année d’une part, et en vous proposant une présentation de l’API des blocs du nouvel éditeur de WordPress ainsi que ma toute fraîche collection de « GutenBlocks », d’autre part.

L’API des blocs de Gutenberg

D’une rédaction monobloc, anarchique et éparse, l’éditeur de contenus riches de WordPress évoluera, à l’occasion de sa prochaine version majeure, vers une rédaction « multibloc« , cohérente et standardisée.

Grâce à Gutenberg, nous disposons dorénavant d’une nouvelle API, celle des blocs, qui apporte une structure commune et stable sur laquelle nous pourrons complètement nous reposer pour tout site WordPress et ce dés la version 5.0.

L’API des blocs stocke la combinaison des blocs utilisée dans nos contenus dans un champ unique de la table wp_posts (très logiquement dans le champ post_content !) tout en délimitant chaque bloc par des commentaires HTML. Ces commentaires sont ignorés de l’affichage produit par le navigateur et interprétés par l’API des blocs au moment du rendu. Cette interprétation nous autorise l’utilisation de contenus statiques, bien sûr, mais aussi l’insertion d’éléments plus dynamiques (il est par exemple possible d’intégrer et d’afficher des widgets). Ingénieux !

Autonomie et maîtrise.

Il y a quelques temps, j’ai pu constater la maîtrise que cette API procure au développeur pour optimiser l’interaction de son code avec l’utilisateur. Le bloc agit comme une zone autonome et étanche qui n’impacte pas les autres blocs. Si une erreur de code est rencontrée, le bloc est neutralisé et un message informe de l’incapacité pour Gutenberg de l’afficher en toute sécurité.

L’intégrateur ou le développeur peuvent également gagner en maîtrise en orientant les utilisateurs sur une combinaison recommandée de types de bloc pour leurs types de contenus, ou encore en neutralisant des types de bloc pour certains rôles ou, pourquoi pas, types de contenu de WordPress.

Illustrons ces deux possibilités ! D’abord, vous pouvez prendre vos rédacteurs par la main en leur préparant un gabarit (« template« ) de blocs. Pour cela il suffit d’ajouter un argument template lorsque vous référencez vos types de contenu. Pour les types de contenu natifs comme les articles et les pages, il faut faire preuve d’un peu d’astuce pour arriver au même résultat.

Je me suis amusé par exemple à intégrer un gabarit de blocs pour guider les contributeurs dans la rédaction de leurs articles, comme illustré ci-dessus. Voici le code que j’ai utilisé pour parvenir à ce résultat.

Pour illustrer la manière dont vous pouvez neutraliser certains types de bloc, je vous propose de rustiner ce que je considère comme un comportement inadapté de Gutenberg. Dans WordPress les contributeurs n’ont pas les droits nécessaires pour téléverser des fichiers ou même pour insérer des media de la bibliothèque du site dans leurs articles. Or Gutenberg leur met à disposition des blocs pour illusoirement braver cet « interdit ». Car, en effet, dés qu’un contributeur essaiera d’ouvrir l’éditeur de media pour inclure un fichier image, audio ou vidéo, il verra apparaître des messages d’erreur liés à son incapacité à réaliser ce type d’opération. Du coup, autant neutraliser ces blocs pour éviter des frustrations inutiles, en attendant que Gutenberg résolve la difficulté. Pour ce faire, il vous suffira d’utilise ce nouveau morceau de code :

GutenBlocks : mon stock de blocs Gutenberg.

Comme je vous l’ai annoncé dernièrement, j’utilise Gutenberg pour ce site et comme vous pouvez le constater ça n’a eu aucun impact sur la présentation de mes vieux articles ! Toutefois, lors de la bascule, je me suis aperçu que j’avais perdu une fonctionnalité que j’utilise énormément : la possibilité d’intégrer des images distantes sans les téléverser mais en utilisant leurs URLs.

Du coup, comme ça me bassinait de faire du va et vient entre les deux éditeurs, j’ai démarré une nouvelle extension que j’ai appelé « GutenBlocks« . Sa première version intégrait un bloc spécifique pour rétablir ma fonctionnalité chérie et pour me faire patienter jusqu’à la résolution de cette régression.

Sur ma lancée, j’ai remplacé le bloc d’imbrication de contenus WordPress (les « WP Embeds ») de Gutenberg par un nouveau GutenBlock pour cette extension. En effet, il m’arrive de fréquemment imbriquer mes propres articles et la prévisualisation ne fonctionne pour l’instant que pour les sites WordPress externes. Tant que j’y étais, j’en ai profité pour tirer une requête (« pull request ») à l’équipe de développement de Gutenberg pour proposer une manière de résoudre cette difficulté.

Ensuite comme je compte bien me créer un tout nouveau thème pour profiter à fond des avancées introduites par ce nouvel éditeur, j’ai commencé à améliorer mon expérience d’édition en me créant un bloc pour insérer mes morceaux de code source que j’héberge sur gist.GitHub.com. En passant les deux bouts de code qui illustrent cet article utilisent ce nouveau bloc, bien entendu.

Enfin je me suis débarrassé d’un « shortcode » que j’utilisais et j’ai remodelé les cartes de téléchargement de mes extensions hébergées sur GitHub.com. Ce dernier bloc est un exemple concret de la possibilité de générer dynamiquement le contenu au moment du rendu.

Puisez dans mon stock !

Cette nouvelle extension intégrera prochainement l’Entrepôt pour vous simplifier ses futures mises à jour, en attendant vous pouvez la récupérer et l’installer manuellement depuis sa carte de téléchargement 🙂