Nous sommes en Mai !

Aussi dans les prochains jours je vous proposerai de tester une première version de l’extension MediaThèque. Ces derniers temps, j’ai travaillé à l’intégration de cette extension dans la configuration Multisite de WordPress. Afin d’entretenir votre appétit, je vous propose de découvrir comment ça se passera pour vos WordPress multisites.

Rappelez-vous, dans cet article, je vous présentais son objectif principal :

Son objectif est de compléter la bibliothèque partagée entre tous les rédacteurs (administrateurs, éditeurs, ou auteurs) de contenus par une MediaThèque individualisée pour tous les utilisateurs de votre WordPress (les rédacteurs, mais aussi les contributeurs, les abonnés ou encore les simples membres dans le cadre des configurations Multisites).

Comme MédiaThéque introduit une gestion alternative des media indépendante des articles, il m’a semblé cohérent qu’elle devait également l’être par rapport aux sites d’un réseau Multisite de l’utilisateur.

Ainsi pour ces configurations, chaque utilisateur disposera de l’intégralité de ses media et pourra les gérer depuis chacun des sites dont il est membre. La vidéo de démonstration ci-dessous vous le prouve !

Voilà ! Je pense que la première version de l’extension « MediaThèque » est fin prête pour enrichir et compléter votre expérience et celle de vos utilisateurs pour vos (et leurs) besoins de partage et de gestion de fichiers media.

Aussi, comme on est jamais trop prudent, cette version bêta devrait permettre aux plus aventuriers d’entre vous d’éprouver cette nouvelle extension et d’éventuellement me faire part des anomalies qui m’auraient échappé. De mon côté, elle me permettra d’ajouter quelques tests unitaires et de continuer à la torturer !

En passant, tant que vous êtes dans les tests, profitez-en pour tester la MediaThèque dans la première bêta de WordPress 4.8.

WordPress 4.8 Beta 1

Je précise que cette période ne consiste pas à me faire part des « ça serait bien si telle fonctionnalité était incluse », on verra ça en temps voulus. En revanche si vous souhaitez contribuer à sa disponibilité dans d’autres langues que le français et l’américain ou directement à la résolution des anomalies que vous auriez identifiées, il vous suffit de faire une « pull request » sur son répertoire de développement.

Je vous rappelle que la singularité de cette extension par rapport à mes précédentes création, c’est qu’elle est « full Rest API ». Elle est donc une belle illustration (imho) des applications intéressantes qu’on peut accomplir grâce â cette API.

Alors, si à ce stade de la lecture, vous vous demandez à quoi peut bien servir cette extension, vous trouverez ci-dessous les épisodes précédents :

Un avant-goût de votre prochaine MediaThèque #WordPress

MediaThèque saura identifier ses disparus

Voici comment s’afficheront les media de votre prochaine MediaThèque

MediaThèque et le Multisite, vos media seront tous disponibles et ce depuis tous vos sites !

Merci à toutes celles et tous ceux qui contribueront.

Ça progresse ! La toute première version stable de MédiaThèque devrait être disponible d’ici quelques jours. Je vous propose de m’aider à me rassurer quant à sa stabilité en testant cette deuxième bêta. D’avance merci à toutes celles et tous ceux qui voudront bien contribuer.

Corrections apportées :

• maintien du dossier parent d’origine lorsque le titre ou la description d’un media d’utilisateur est modifié depuis l’interface d’édition en back-office.
• neutralisation du chargement des scripts et des styles de la MediaThèque pour les contextes relevant de la gestion des widgets et du customizer.
• intégration d’un « hook » de type filtre pour permettre l’inclusion de champs additionnels dans l’interface d’édition des media d’utilisateur en back-office.
• nettoyage des tirets dans le nom des réglages d’utilisateur pour éviter des incohérences dans le chargement des « WordPress Pointers ».
• amélioration du chargement des traductions pour s’assurer qu’il intervient suffisamment tôt afin que toutes les chaînes soient traduites.
• amélioration de la cohérence du type d’interface utilisée par rapport au rôle de l’utilisateur (complète ou bridée) et prise en charge des affichages en front-end en lien avec l’éditeur de texte riche de WordPress (WP Editor).

Tests unitaires:

• amélioration de la « Factory » spécifique aux objets de MediaThèque pour que soit intégrer les dossiers.
• ajout de tests unitaires pour couvrir les fonctions de déplacement de media d’utilisateur, de suppression de dossiers et de suppression d’utilisateurs.
• intégration du service Travis CI.

Documentation :

Un wiki en anglais a été initialisé sur le dépôt Github de l’extension.

Je suis très heureux de vous annoncer cette nouvelle version de l’extension qui équipe votre WordPress d’un système de partage d’idées pour ses utilisateurs.

La version 2.5.0 nécessite la version 4.7 de WordPress et a été testée avec succès sous sa 4.8 (dernièrement partagée en bêta 2).

Deux évolutions majeures ont été introduites pour enrichir votre expérience rédactionnelle

Ce que vous voyez se rapproche de ce que vous aurez !

• L’éditeur de WP Idea Stream intègre désormais les « editor styles » du thème actif afin de vous donner une meilleure idée de la manière dont les contenus seront présentés une fois publiés.
• Il affichera – également – les codes d’insertion (« embeds ») que vous aurez ajoutés.

J’ai également profité de cette version pour anticiper la prochaine publication de la première version stable de MediaThèque. L’association de ces deux extensions vous permettra de proposer à vos utilisateurs d’intégrer des media aux idées partagées et ce directement depuis le formulaire de dépôt ou d’édition en « front-end ».

Le bouton « Add User Media » pour utiliser la MediaThèque

Mettre à jour WP Idea Stream.

1. Télécharger le fichier wp-idea-stream.zip
2. Faire une sauvegarde de votre base de données.
3. Désactiver WP Idea Stream avant de le supprimer.
4. Transférer le fichier wp-idea-stream.zip sur votre WordPress depuis l’interface d’ajout des extensions.
5. Réactiver WP Idea Stream depuis l’interface d’administration des extensions de votre WordPress.

C’est le grand saut ! La toute première version stable de MediaThèque est prête à équiper vos WordPress d’une bibliothèque de media à la fois alternative, complémentaire et un brin plus astucieuse à, de et que celle qui est intégrée nativement. Etant donné que MediaThèque se repose énormément sur la Rest API et les content endpoints de WordPress, elle requiert à minima la version 4.7 de WordPress.

NB: If you only understand English, i advise you to read the Plugin’s wiki on Github.

Publier des fichiers.

L’interface de gestion des fichiers de la MédiaThèque d’un abonné.

Dans cette nouvelle extension, les media sont envisagés comme des contenus à part entière (et non pas seulement comme des accessoires de contenu).

Potentiellement, tout utilisateur inscrit sur votre WordPress peut publier des media et les rendre accessible à tous (Navigation « Public » de l’interface) ou aux seuls utilisateurs connectés sur le site (Navigation « Privé » de l’interface). Pour ajouter de nouveaux media, il suffit d’activer l’outil de transfert en cliquant sur le bouton « Nouveau(x) Fichier(s) » et de glisser-déposer le ou les fichiers de votre choix.

Les fichiers transmis sont fortement dépendants de leur propriétaire (ou auteur) et ce jusque dans l’organisation du système de fichiers de votre instance WordPress.

Ranger ses media.

Créez des répertoires pour ranger vos media.

Grâce à la fonctionnalité des répertoires, les utilisateurs choisissent librement l’organisation qui leur convient le mieux (ex: type de fichiers, années, lieux…). Une fois le répertoire créé, on peut l’ouvrir pour y ajouter des fichiers ou d’autres répertoires.

Il est possible également d’utiliser le « glisser-déposer » comme illustré ci-dessus. Ce « glisser-déposer » fonctionne également sur le fil d’ariane lorsqu’on veut remonter le fichier d’un niveau. Il n’y a pas de limitation quant à la profondeur et à la largeur du nombre de répertoires.

Modifier ou supprimer des éléments de sa bibliothèque personnelle.

La modale pour éditer le titre et la description d’un media.

En cliquant sur l’icône en forme de crayon, il est possible de modifier le titre du media et de lui ajouter une description. Depuis cette fenêtre, lorsqu’un media a été attaché à un ou plusieurs contenus, les titres de ces derniers sont listés.

L’icône en forme de poubelle permet de supprimer définitivement un media. Un autre évènement peut générer la suppression de media : la suppression d’un utilisateur.

Partager des fichiers ou des répertoires.

La vue d’un media ou d’un répertoire.

En cliquant sur l’icône en forme d’oeil, on atteint la page du media ou comme pour l’exemple ci-dessus du répertoire. Dans le cas du répertoire, cette page listera les miniatures de tous les fichiers qu’il contient. Pour afficher un de ses media en particulier, il suffit de cliquer sur cette miniature. Le clic sur l’icône affiché sous la miniature déclenche, quant à lui, le téléchargement du fichier.

Le rendu d’un code WP Embeds pour un répertoire

En utilisant le permalien du media ou du répertoire, il est possible de partager tout fichier public sur tout site équipé de WordPress.

Enfin il existe également un shortcode [mediatheque] qui permet d’afficher tous les éléments publics des bibliothèques personnelles des utilisateurs. Voici qui devrait contenter tous ceux qui voudraient présenter à leurs visiteurs tous les media disponibles en téléchargement.

Superviser les fichiers des utilisateurs.

L’interface des administrateurs

L’administrateur du site, dispose d’une interface plus élaborée depuis laquelle il peut visualiser l’espace occupé par chacun des utilisateurs du site. En cliquant sur un des avatars listés, il accède à la bibliothèque personnelle de l’utilisateur correspondant et peut consulter chacun de ses media, les modifier ou encore supprimer tout fichier.

Attacher des media à d’autres contenus.

La bibliothèque native de WordPress est mutualisée entre tous les rédacteurs de contenus (c’est à dire : les rôles d’administrateur, d’éditeur et d’auteur). Lorsqu’un de ces rôles rédige de nouveaux articles, de nouvelles pages ou encore tout type de contenu personnalisé, il peut attacher des entrées de cette bibliothèque grâce à l’éditeur de media de WordPress. Cet éditeur s’affichera dans une fenêtre modale lorsque sera cliqué le bouton « Ajouter un media » (au dessus de l’éditeur de texte riche).

Le menu « MediaThèque » dans l’éditeur de media de WordPress

Ces mêmes rôles, ainsi que le rôle de contributeur (qui est, quant à lui, interdit de bibliothèque WordPress !) pourront également accéder à leur MediaThèque personnelle grâce au menu du même nom et qui est logé dans la barre latérale (gauche) de l’éditeur de media. Ils pourront bien entendu transmettre de nouveaux fichiers ou créer de nouveaux répertoires et surtout ils seront en mesure de directement intégrer ces éléments dans leur contenu.

Edition des préférences d’affichage d’un media intégré.

Par ailleurs, une fois le media injecté en cliquant sur le menu contextuel « modifier », ils auront la possibilité d’affiner la manière dont il sera affiché une fois le contenu publié (ou de l’enlever du contenu à l’aide du menu contextuel correspondant).

Tracer les media ayant disparus de leur contenu de rattachement.

Il faut savoir que l’url absolue vers le fichier n’est jamais utilisée, et qu’aucune balise html n’est ajoutée au contenu dans le cadre de cet attachement. Lorsqu’un élément de la MediaThèque est inséré, seul un permalien enrichi (d’une ou plusieurs variables spécifiques) sera sauvegardé dans le contenu. L’extension utilise ensuite l’API des WP Embeds de WordPress pour construire au moment du chargement de la page le code html nécessaire au rendu du media. Grâce à cette technique, MediaThèque est en mesure de vérifier la bonne existence d’une image, par exemple, avant de l’afficher. Si toutefois cette image avait été supprimée, elle ne serait – ni même toute empreinte résiduelle de l’image – affichée et l’administrateur en serait informé par la réception d’un email. L’article ci-après détaille ce dispositif.

MediaThèque saura identifier ses disparus

Paramétrer MediaThèque

Les options de MediaThèque

Depuis l’onglet « MediaThèque Utilisateurs » des options des media, l’administrateur peut personnaliser certains éléments du comportement de l’extension. D’abord il peut décider d’un rôle minimal à détenir pour qu’un utilisateur puisse en profiter. Trois possibilités sont offertes : l’utilisateur connecté, l’abonné ou le contributeur. Les autres rôles pouvant utiliser la bibliothèque mutualisée native quoiqu’il arrive, ils pourront donc également profiter quoiqu’il arrive de leur bibliothèque individualisée.

Ensuite, pour tous les rôles inférieurs à celui d’administrateur, il sera nécessaire de définir les types de fichier autorisés. Par défaut, seuls les fichiers PNG, JPG, GIF, PDF et RTF sont activés pour les autres rôles.

Enfin, MediaThèque inclut une gestion locale des images de profil pour les utilisateurs. Vous pouvez à tout moment désactiver cette dernière.

Disposer de tous ses fichiers depuis tout site d’un réseau Multisite.

Cerise sur le gâteau! A la différence de la bibliothèque native de WordPress, la bibliothèque individuelle des utilisateurs ne dépend pas du site sur lequel il se trouve mais est accessible en intégralité depuis n’importe quel site du réseau et ce quelque soit son rôle. Je vous invite à lire l’article suivant pour en savoir plus à ce sujet.

MediaThèque et le Multisite, vos media seront tous disponibles et ce depuis tous vos sites !

Installation et Mise à jour

MediaThèque est hébergé sur Github. Ces deux opérations sont donc pour l’instant très manuelle. Je vous conseille de télécharger le fichier « mediatheque.zip » qui sera attaché à chaque note de version. Il sera prêt pour un emploi depuis l’interface d’ajout des extensions de WordPress.

En cas de mise à jour, il s’agira (après avoir sauvegardé sa base de données – c’est fortement recommandé) de désactiver l’extension, de la supprimer avant de l’installer de nouveau.

Reconnaissance, excitation, stress, soulagement, nostalgie, émerveillement, exténuation et fierté. Cette semaine, si particulière pour un contributeur WordPress français habitant à Paris, m’aura fait passer par tous ces états et procurer d’intenses émotions.

Reconnaissance.

Mon badge de participant au Community Summit

En tant que représentatif de l’équipe community pour l’année 2017, j’ai pu donner mon avis sur ces différents sujets. Avant même cette possibilité de libre expression qui nous ai donné, l’écoute est très instructive. Ainsi, non seulement je suis honoré d’avoir été parmi la centaine de participants, mais je sais aussi avoir été extrêmement privilégié d’avoir eu la chance d’apprendre au contact des présents.

Excitation et stress.

Mon badge de membre de l’équipe d’organisation du WordCamp Europe 2017

Ayant également contribué aux missions de l’équipe locale, qui était guidée par Jenny, et plus particulièrement sur l’accès internet et la mise en place de réseaux Wifi pour ce « Contributor Day », le WordCamp et l' »After party », j’appréhendais d’éventuelles difficultés quant à ces réseaux. Je me rappelais notamment du premier WordCamp Europe à Leiden durant lequel l’infrastructure avait été mise à rude épreuve.

Et puis je m’étais mis la pression tout seul ! Contribuer à faire du « Contributor Day » une réussite me tenait vraiment à coeur. D’abord parce que cela couronnait une préparation hyper riche avec les représentants des équipes de contribution et les orateurs. Ensuite parce que le « Contributor Day », c’est aussi séduire de nouveaux entrants pour qu’ils s’investissent dans le projet WordPress. Enfin, c’était le premier événement de ce genre qui se déroulait en France et je caresse l’espoir qu’il infusera dans les prochains mois pour apporter plus régulièrement cette « french touch » aux codes des projets de la fondation.

Résultat : un peu plus de 500 personnes (organisateurs, représentants d’équipe, orateurs et volontaires compris) ont profité des installations du lieu pour apprendre, faire de nouvelles connaissances, en retrouver d’autres et bien entendu s’investir. Ils ont pu assisté à 13 ateliers, 4 conférences et s’engager dans la contribution aux 19 équipes que nous avons constituées.

La plupart de ces équipes sont issues de cette liste du « Make« , nous avons toutefois souhaité faire des équipes spécifiques pour les domaines JavaScript et de la Rest API lesquels sont habituellement inclus dans celui du Core. L’idée était de les mettre en valeur car ce sont deux des priorités du projet :

• Développer les compétences des contributeurs WordPress en JavaScript,
• utiliser plus abondamment la Rest API pour les fonctionnalités d’administration de WordPress.

Par ailleurs, lors de nos échanges préparatifs avec les représentants de l’équipe du Core, il est apparu opportun d’essayer de leur permettre de gagner du temps en élaborant un atelier spécifique pour prendre en charge la construction des environnements de développement/contribution des nouveaux contributeurs. C’est la raison pour laquelle nous avons demandé à des membres de l’équipe de développement de VVV d’accompagner les débutants dans cette tâche préparatoire en début de matinée et en début d’après-midi.

Soulagement.

Crédits Photo Olivier Gobet, sur Flickr.

Ensuite parce qu’au cours de mes escalades, j’avais pu voir le sourire et la motivation de ces participants, la formidable envie des représentants des équipes et des orateurs de leur transmettre des savoirs-faire ainsi que le travail exceptionnel des volontaires et de mes collègues organisateurs.

Aussi parce que nous avions fait de bons choix quant aux partenaires pour le lieu et l’accès internet car ils ont su être très réactifs pour gérer les imprévus. Et puis parce qu’on avait des résultats et des contributions concrètes. Chacun des représentants des équipes se sont succédés et ont partagé ce qui avait été réalisé collectivement et c’est impressionnant.

Enfin, grâce à l’investissement des cameramen, nous avons aussi des contenus très riches à partager avec toutes celles et ceux qui n’ont malheureusement pas pu être présents. La capture de ces précieux moments sera très prochainement disponible sur WordPress.tv et je vous invite à les vivre ou à les revivre.

Avec Rocio, Ibon, Andrès, Aleksandar, Francesco, Xavier, nous pouvions donc, le sentiment du devoir accompli, passer le témoin aux conférences du WordCamp pour poursuivre la magie de ces 3 journées extraordinaires.

Intenses retrouvailles.

Laurens, Slava, Boone, Moi et Henry chez Pietro (nom de la version 2.4.0 de BuddyPress).

Ils ont pu apprécier la grande variété des contenus qui leur était proposée : des conférences, un salon des sponsors, des ateliers de sponsors, des « tribe meetups », un « happyness bar », des espaces de networking, sans oublier deux tables communautaires pour s’engager à la fois dans les communautés locales françaises ou internationales. En passant « big up » à mes proches de l’association de WP Paris pour leur implication dans la table communautaire francophone.

Au delà des contenus, ça a été pour eux et pour moi l’occasion de faire d’intenses retrouvailles. J’utilise ce terme plutôt que « rencontres » me concernant car la plupart du temps nous avons déjà fait connaissance en ligne et nous nous retrouvons dans la vraie vie.

Ainsi, j’ai été enchanté et très ému de retrouver Boone, Paul, Henry, Slava, Marion, Bowe, Laurens, Sven, Jenny, Rocio, Emilie, Aleksandar, Ibon, Andrès, Xavier, Thierry, Grégoire, Benjamin, Remkus, Taco, Paolo, Francesca, Emanuel, Milan, Luca, Sonja, Florian, Isabelle, Olivier, Adrian, K.Adam, Zac, Félix, Ryan, Adam, Alan, Andrea, Jenny, Sven, Thomas, Tammie, Sergey, Jon, Bridget, Lorelei, Tom, Pascal, Eric, Marc, Claire, Karine, Sylvie, Julio, Daniel, Willy, Valentin, Aurélien, Benjamin, FX, Didier, Jérôme, Amaury, Julien, Alex, Maxime, Chanfi, Valérie et toutes celles et ceux dont j’ai oublié le prénom (dsl).

On l’a fait!

Le gars pas très net, c’est moi! Crédits Photo Olivier Gobet, sur Flickr

Aujourd’hui, je peux vous dire que c’est une aventure humaine à la fois extraordinaire et très exigeante. Non seulement, nous devons donner de notre temps mais nous devons surtout donner de notre personne pour :

• accepter de se mettre au service des autres,
• accepter de rester complètement désintéressé de nous-même,
• absorber les tensions,
• dépasser notre timidité parfois,
• prendre des initiatives,
• rester humble et bienveillant.

Je suis très fier d’avoir pu aller jusqu’au bout de cette aventure et du succès du WordCamp Europe 2017. Bravo Jenny, bravo Paolo, bravo aux organisateurs, aux volontaires, aux sponsors, aux intervenants et aux participants. En résumé, bravo WordPress.

Le chapiteau a été démonté et la caravane du WordCamp Europe a repris sa route pour sa prochaine escale : Belgrade en Serbie.

Vive le WordCamp Europe 2018 !

Ça fait un peu plus de deux mois que j’ai retiré mes créations de l’annuaire officiel des extensions WordPress. Bien que je sois très heureux de ne plus avoir à supporter la minorité des « useurs » irrespectueux, ingrats et agressifs qui fréquentent de plus en plus cet annuaire, je regrette de ne plus pouvoir faire profiter à la majorité (même si très silencieuse) d’une fonctionnalité très intéressante de ce « Plugins Directory » : son intégration avec vos WordPress.

En effet, depuis la version 2.5 de WordPress, vous pouvez directement installer de nouvelles extensions et les mettre à jour d’un simple clic depuis un écran spécifique de l’interface d’administration de votre WordPress.

Entrepôt : une nouvelle relation de proximité entre vous, moi et potentiellement d’autres auteurs d’extensions !

Voici pourquoi, j’ai conçu l’Entrepôt. D’abord pensé pour lister mes extensions dans l’administration de vos WordPress, il m’est apparu comme évident qu’ouvrir cet espace à mes paires avait du sens. En tout cas, j’ai tout prévu pour que des auteurs d’extensions comme moi puissent enrichir cette liste grâce à leurs réalisations.

L’onglet Entrepôt liste les extensions enregistrées

Ainsi, l’Entrepôt rend plus simple les opérations d’installation et de mise à jour des extensions gratuites hébergées sur GitHub.com qui y sont référencées pour les utilisateurs.

Entrepôt

Entreposez vos dépôts GitHub.com

Les auteurs d’extensions qui le souhaiterons pourrons soumettre des « pull requests » qui contiendront l’ajout d’un fichier décrivant leur extension en vue de l’inscrire dans l’Entrepôt. Je ne vais pas entrer dans le détail des informations qui seront dans ce fichier, mais les lecteurs intéressés retrouverons toute la documentation nécessaire pour pouvoir s’inscrire dans l’Entrepôt depuis son wiki.

Chaque auteur gardera donc le contrôle total sur ses dépôts GitHub et pourra toujours profiter des points forts du service GitHub.com. Ils devront néanmoins :

• avoir la discipline d’avoir recours à sa fonctionnalité « releases » pour publier les versions stables de leurs extensions,
• avoir le sérieux de veiller à la compatibilité de leurs développements avec la dernière version de WordPress,
• respecter l’unicité du nom de leur extension par rapport à celles déjà entegistrées dans l’Entrepôt mais aussi sur WordPress.org (ce qui implique également de ne pas référencer son extension à la fois dans l’Entrepôt et sur WordPress.org : il faudra choisir),
• distribuer leurs extensions gratuitement.

L’Entrepôt ne fait pas de favoritisme et n’affiche aucune statistique au sujet des extensions référencées. L’affichage s’y fait aléatoirement (y compris pour votre serviteur !). L’Entrepôt sollicite directement GitHub.com sans passer par un service tiers, aucune donnée concernant l’utilisateur ou sa configuration n’est récoltée, transmise ou stockée.

Pour l’ouverture de ses portes, l’Entrepôt expose trois de mes extensions (les autres suivront, y compris vraisemblablement ClusterPress).

Hello !

Pour ceux qui n’avaient jamais entendu parler de l’Entrepôt jusqu’à présent, je vous invite à faire connaissance avec lui en lisant la page de ce site qui lui est dédiée.

Entrepôt

Ensuite, et pour les autres, j’attire votre attention sur les trois prochaines fonctionnalités de l’Entrepôt qui devraient prochainement vous simplifier la vie que vous soyez un utilisateur ou un créateur d’extensions WordPress.

Gestion des dépendances.

Les dépendances seront indiquées dans les cartes décrivant les extensions depuis l’onglet de l’Entrepôt.

L’Entrepôt innove en proposant d’informer l’utilisateur qu’une extension dépend d’une autre. Voici qui est très utile pour les extensions BuddyPress que j’avais créées ! D’ailleurs, cette prochaine version (la 1.1.0) enrichira la liste des extensions disponibles de deux réalisations BuddyPress, l’histoire d’illustrer cette fonctionnalité.

Ainsi dans l’exemple ci-dessus et ci-après, une extension d’une autre extension ne pourra être installée ou activée que si l’extension étendue est bien installée et activée sur le site.

Le bouton d’activation ne sera pas affiché en cas de dépendance(s) insatisfaite(s). Dans cet exemple BuddyPress est manquant.

Gestion des mises à niveau.

L’interface d’administration des mises à niveau des extensions enregistrées sur l’Entrepôt.

Lorsqu’une extension a besoin de procéder à des opérations de mise à niveau de votre base de données à l’occasion d’une nouvelle version par exemple, elle est souvent obligée d’inclure un certain nombre de fonctions et des problèmes peuvent se poser lorsque les données à manipuler sont nombreuses.

Grâce à l’introduction dans la version 1.1.0 de l’Entrepôt d’une nouvelle API de gestion des mises à niveau des extensions : tout sera beaucoup plus simple. La documentation de l’Entrepôt sera prochainement mise à jour pour détailler l’utilisation de cette API, en attendant l’animation ci-dessus vous la montre en pleine mise à niveau de la version 2.0.0 de BP Reshare (qui arrivera elle aussi prochainement !).

Un centre de notifications qui sait se faire discret !

Aïe, parfois les extensions abusent des notifications en occupant une belle partie de votre écran d’administration.

Depuis un certain temps j’observe une certaine lassitude chez les utilisateurs concernant la pratique des extensions qui consiste à utiliser les « admin notices » pour forcer l’affichage d’informations qui sont parfois très éloignées des fonctions de l’extension. D’ailleurs la taverne avait même appelé les développeurs à observer une certaine retenue.

Pour ma part je reste très étonné que l’équipe de validation des extensions de WordPress.org ne fasse rien et tolère cet usage qui ressemble parfois à de la publicité non sollicitée.

Toutefois, à la décharge de ces développeurs, le core de WordPress ne leur propose pas réellement d’autres espaces pour afficher ces informations (ni même un outil de mise à niveau ou de gestion des dépendances d’ailleurs!).

Le nouveau centre de notifications de l’Entrepôt : si discret, si indispensable !

Chers utilisateurs de l’Entrepôt, vous serez les premiers à garder un écran vierge de notifications abusives ! En effet la version 1.1.0 de l’Entrepôt introduira un nouveau centre de notifications qui se logera dans un des onglets supérieurs de votre écran (à côté de ceux des options de l’écran et de l’aide).

Ce nouvel onglet vous dira le nombre de notifications que vous devrez consulter et en cliquant dessus, vous les retrouverez organisées selon leur type (Erreurs, Infos ou Mises à niveau). Pour les notifications de type « erreurs » ou « infos », vous pourrez, lorsque ça l’exige (ex: publicité non sollicitée), vous en débarrasser définitivement !

Voilà il me reste à terminer la documentation quant à ces nouveautés, en attendant, vous pouvez m’aider en testant la version 1.1.0-beta1 pour me faire part d’éventuelles difficultés ou bugs.

Bon 14 juillet à toutes et tous

Après une hibernation de plusieurs années, BP Reshare s’apprête à re-prendre du service. Re-découvrez cette extension du composant des Activités de BuddyPress car elle a été complètement re-écrite en essayant :

• d’éviter la duplication des contenus,
• de privilégier le recours à JavaScript sur l’utilisation des « BP Legacy template hooks » (qui peuvent se révéler incertains en fonction du thème de l’utilisateur),
• d’améliorer la manière dont persistent les données qui lui sont nécessaires,
• d’explorer une nouvelle voie pour classer les activités : en fonction de la date de leur dernier évènement, dans notre cas selon la date de leur re-partage.

La version 2.0.0 c’est d’abord la 1.0.0.. en mieux !

Les activités personnelles d’un utilisateur.

De la même manière que vous pouvez RT des tweets intéressants, avec BP Reshare, les membres de votre communauté BuddyPress pourrons Re-partager les activités intéressantes dans leur flux personnel.

Mes activités que d’autres ont re-partagé

Ils retrouveront, depuis leur profil, leurs activités re-partagées par d’autres membres.

Les activités que j’ai repartagées directement dispo dans la page des activités du site.

Depuis la page des activités du site, un nouvel onglet leur permettra de rapidement accéder aux activités qu’ils ont re-partagées.

Liste des utilisateurs ayant re-partagé ou mis en favoris mon activité.

En affichant l’activité dans sa vue dédiée (« single »), ils pourront non seulement consulter les utilisateurs qui l’ont re-partagée mais aussi ceux qui l’ont mise en favoris. En cumulant nombre de commentaires, de re-partages et de mises en favoris, l’auteur d’une activité peut désormais avoir une bonne idée de la popularité de cette dernière.

La version 2.0.0 c’est ensuite.. de nouvelles fonctionnalités !

Tiens! Une de mes activités a été repartagée

Le composant des Notifications de BuddyPress est activé ? Alors, lorsqu’une de ses activités sera re-partagée, l’auteur en sera informé depuis une nouvelle entrée dans son centre de notifications. Vous pensez qu’un « pull email » de cette dernière serait le bienvenu ? Un peu de patience, c’est prévu dans les options.

Re-partager ou Mettre en favoris un article directement depuis l’article.. Grand luxe!

Le composant de suivi des Sites (ou du site si vous n’utilisez pas un réseau multisite) est activé ? Dans ce cas vos membres connectés pourrons directement re-partager ou mettre en favoris les activités liées à vos articles depuis la page de l’article.

Choisissez vos options.

Alertes Email, possibilité de re-partage des types d’activités, ou encore votre préférence quant à l’ordre dont sont listées les activités (par date de création ou de re-partage) : voici trois options que vous pourrez personnaliser depuis les réglages de BuddyPress.

Qui dit réécriture, dit changements majeurs et dit beta-testez !

44 fonctions ou classes ont été dépréciées depuis la version 1.0.0, si vous en étiez un utilisateur je vous conseille vivement de tester cette première beta de la 2.0.0.

BP Reshare sera dans l’Entrepôt !

Par ailleurs, BP Reshare intégrera l’Entrepôt à l’occasion de la sortie de sa version 1.1.0 et sera la première extension à profiter de sa nouvelle API de mise à niveau. Une nouvelle fois, si vous étiez un utilisateur de BP Reshare 1.0.0, installez l’Entrepôt pour profiter d’une automatisation de ces tâches. Autrement préparez-vous à mettre les mains dans le cambouis !

Je suis très fier de vous annoncer la publication d’une nouvelle version majeure pour l’Entrepôt. La 1.1.0 corrige un certain nombre de bugs mineurs et introduit des évolutions bénéfiques à la fois aux utilisateurs et aux créateurs d’extensions. Gestion des dépendances, des mises à niveau et des notifications d’administrateur sont les trois principales nouveautés comme évoqué dans l’article suivant.

Découvrez les prochaines nouveautés de l’Entrepôt

Trois nouvelles extensions rejoignent l’Entrepôt !

Les 3 petites nouvelles !

Deux extensions BuddyPress : BP Idea Stream et la toute fraîche 2.0.0 de BP Reshare ainsi qu’AD ACF Builder, une extension d’Advanced Custom fields Pro, font leur entrée dans l’Entrepôt.

Bienvenue et merci à Thomas !

Thomas Villain, designer et développeur WordPress, est l’heureux papa d’AD ACF Builder et je le remercie de faire confiance à l’Entrepôt pour distribuer son extension. Cette dernière vous propose d’intégrer un constructeur de mise en page basé sur les champs flexibles d’ACF Pro (version 5.6+) directement depuis vos pages ou articles.

La description d’AD ACF Builder.

Mettez vos Entrepôts à jour !

Si vous avez déjà installé la version 1.0.0 de l’Entrepôt, cette mise à jour peut se faire directement depuis l’administration des extensions de votre WordPress. Si c’est la première fois que vous installez l’Entrepôt, récupérez l’archive .zip en cliquant sur le bouton Télécharger ci-après. Il vous suffira de transférer l’archive sur votre site en utilisant l’installateur d’extensions de WordPress.

Equipez vos groupes BuddyPress d’une nouvelle page de profil pour permettre à leurs administrateurs de présenter leur groupe !

Dernièrement, on m’a demandé de créer une extension pour répondre à ce besoin. Or comme c’était une demande récurrente au fil du temps, j’ai pensé que cette nouvelle extension BuddyPress pouvait aussi vous intéresser.

Sa particularité est de se reposer sur l’API des xProfile de BuddyPress, laquelle a largement fait ses preuves pour permettre aux membres de décrire leur profil. Alors je me suis dit, pourquoi ne pas l’utiliser d’autant qu’un ticket sur l’environnement de suivi du développement de BuddyPress le suggère.

L’avantage, c’est que les administrateurs de la communauté devraient très vite comprendre comment créer de nouveaux champs de profil pour les groupes de leur BuddyPress. En effet, non seulement j’utilise l’API des xProfile, mais aussi son interface d’administration !

Interface de gestion des champs de profil de Groupes

Une fois les champs créés, vos administrateurs de groupe retrouveront une nouvelle page « À propos de nous » dans leur groupe. Depuis l’interface de gestion de cette page, ils pourront personnaliser ces champs. En cas de création d’un nouveau groupe, le créateur retrouvera lui aussi une étape pour définir le profil de son groupe.

Etape de création des champs de profil.

Enfin, les utilisateurs désireux de rejoindre votre groupe pourrons alors consulter cette page « À propos de nous » pour avoir une meilleure idée du profil de ce groupe et des membres qui le constituent.

Nous!

L’extension Profil de Groupes sera prochainement disponible dans l’entrepôt et les plus impatients d’entre vous peuvent d’ores et déjà télécharger sa version 1.0.0 depuis GitHub

A quoi sert un thème WordPress ?

D’abord le guide officiel du créateur de thèmes précise qu’il s’agit d’un ensemble de fichiers intégrant des gabarits (templates PHP) , des règles de mise en page, des palettes de couleur, des typographies, des éléments graphiques, des catalogues de langue, voire des idées d’interaction avec l’utilisateur.

Son rôle principal est de puiser dans les contenus de votre site pour les afficher dans le navigateur de l’utilisateur. Le thème définit l’apparence de votre site laquelle contribue à engager vos visiteurs en plus d’être esthétique.

Le guide recommande également de limiter le champ d’action du thème au contrôle de la présentation du contenu pour laisser la maîtrise du comportement et des fonctionnalités de votre site à WordPress et à ses extensions.

La plupart des thèmes sont (selon moi) incomplets !

Il y a des milliers de thèmes sur le répertoire officiel de WordPress et sur de nombreuses places de marché. Un ou plusieurs thèmes « par défaut » sont par ailleurs inclus dans WordPress depuis quasiment l’origine du logiciel. Au début il y a eu « WordPress classic » puis « Kubrick » et à partir de 2010, chaque année a le droit à son « Twenty ».

Les thèmes ont su s’adapter à pratiquement toutes nos évolutions en matière de consommation des sites internet, dont la plus importante est la mobilité. Toutes sauf une et ce depuis l’origine.

Je remarque ainsi que la majorité (pour ne pas dire la totalité – ça serait trop long de vérifier !) des thèmes néglige voir se désintéresse totalement de la manière dont s’affichent les contenus de votre site en dehors de votre site et en particulier lorsque celui-ci s’invite dans les messageries email des utilisateurs.

Description de TwentySeventeen

Nous sommes en 2017, TwentySeventeen a introduit des innovations intéressantes avec les contenus de démarrage ou encore ses quatre sections personnalisables pour la page d’accueil. C’est un excellent thème qui s’adapte à la taille de l’écran du terminal utilisé, etc.. Sauf que lorsque qu’un des visiteurs de votre site s’y inscrit, il reçoit ça dans sa messagerie électronique :

Quel accueil !

On ne peut pas dire que cette apparence soit très engageante et le contraste du texte brut avec l’interface très élaborée du site est saisissant !

Certains diront qu’il existe des extensions pour rendre plus avenantes ces notifications email. Certes, mais qui de l’extension ou du thème connait le mieux l’apparence du site ? Il me semble que c’est le deuxième

Vingt DixSept, un gamin de 2017.

Je reconnais que les thèmes ont une circonstance atténuante. L’envoi d’un email comprenant une partie riche et une alternative brute n’est pas encore pris en charge par WordPress. Cette lacune révélée en novembre 2010 voit son traitement repousser à toujours plus tard, de version en version (« future release »). Nous sommes bientôt en 2018, espérons que TwentyEighteen permettra d’introduire une logique de gabarits et de balisage pour ces contenus particuliers et pourquoi pas contribuer à la résolution de cette lacune.

Description de Vingt DixSept

En attendant, voici un thème enfant de TwentySeventeen qui, au delà de ses légères adaptations de la présentation de l’entête de son parent, de l’intégration d’une page de maintenance et d’une personnalisation du rendu des articles imbriqués, propose de s’intéresser à l’apparence des notifications email générées par votre site WordPress.

Section « Modèle d’email » du Customizer

Une fois activé, vous pourrez rejoindre la section « Modèle d’email » du Customizer pour personnaliser l’apparence des notifications de WordPress. Si vous utilisez le « Custom Logo » ou le menu des liens sociaux, vous pouvez choisir de les intégrer ou non à vos envois et les couleurs d’arrière plan et de soulignement de l’entête sont personnalisables.

Vos utilisateurs recevront alors leurs emails dans le format accepté par leur logiciel de messagerie (HTML ou texte brut).

L’email généré lors de l’inscription d’un nouvel utilisateur

Vous remarquerez que le « design » n’est pas mon fort, le principal intérêt de ce thème est surtout de suggérer une logique de gabarits et un exemple d’utilisation de la technique pour générer un email comportant à la fois une présentation riche et son alternative brute. N’hésitez pas à vous en inspirer pour vos propres thèmes pour les rendre plus complets !

La version 4.9 de WordPress est en approche. Elle contiendra de nouvelles fonctionnalités enthousiasmantes dont la plupart ont déjà été abordées dans d’autres sites. Pour moi cette 4.9 restera la triste version qui aura évacuée « Press This » du « core » dans une grande indifférence.

Source : Changeset 41584 – WordPress Trac

Ajout du signet intelligent Press This à la barre de favoris de Chrome

Pour ceux qui croisent pour la première fois la juxtaposition de ces deux termes anglais qu’on pourrait traduire par « Pressez ceci », il s’agit de la fonctionnalité qui permet de déclencher l’écriture d’un nouvel article pour votre blog depuis un signet « intelligent » de votre navigateur. L’avantage de ce petit morceau de code JavaScript est qu’il transmet un certain nombre d’informations (telles que l’url de la page affichée dans le navigateur, son titre ou encore votre éventuelle sélection de texte dans cette page, etc…) à votre WordPress.

L’éditeur « Press This »

Un éditeur s’affiche alors dans une nouvelle fenêtre de votre navigateur et WordPress vous propose, cerise sur le gâteau, une liste de media qu’il a récupérés en inspectant la page en question. Vous pouvez alors très simplement utiliser une ou plusieurs de ces illustrations pour enjoliver votre nouvel article.

Rapide et astucieuse fenêtre surgissante…

C’est de cette manière que la fonctionnalité avait été décrite lors de son intégration au « core » de WordPress à l’occasion de sa version 2.6.

WordPress 2.6

A l’occasion de la version 4.2, « Press This » avait bénéficié d’une rénovation complète suite aux travaux réalisés par l’équipe du « feature as a plugin Press This Revamp« .

WordPress 4.2 “Powell”

Dans son descriptif, la note de version insistait sur la capacité de la fonctionnalité à simplifier et à accélérer notre manière de partager du contenu. Nous étions en avril 2015 à l’époque, et je suis toujours d’accord avec cet avantage qui est d’autant plus appréciable lorsque notre site est hébergé sur un Intranet.

… pourtant désintégrée du Core dans la prochaine 4.9…

Bookmarklets were popular seven – eight years ago, and now are considered mostly « old tech ».

Comme l’explique la description de ce ticket, malheureusement, la fonctionnalité n’est plus suffisamment utilisée de nos jours (ce qui devait déjà être le cas en 2015 en passant…), à tel point qu’il semble superflu de communiquer sur son retrait du « core » ! C’est par hasard que j’ai découvert que la classe WP_Press_This n’était plus disponible pour une des extensions BuddyPress que j’utilise sur un Intranet. Pourtant, pour éviter ce type de surprises je suis abonné aux articles du « Make« . Or après vérifications, rien n’a été, à ce jour, écrit sur le sujet. La dernière nouvelle concernant « Press This » remonte précisément à 2015

Au moment de l’écriture de cet article, pas d’infos publiées sur le Make…

… et désormais disponible sous la forme d’une extension.

Press This

Ouf ! N’ayez pas peur de la bannière psychédélique utilisée pour l’extension, c’est sans doute pour renforcer le fait que cette fonctionnalité est démodée (ou has been). Personnellement, je l’utilise et j’y suis très attaché. Elle a toujours été près de moi depuis la version 2.7 de WordPress au moment où j’ai fait connaissance avec ce logiciel. La version 4.9 restera donc pour moi, quoiqu’il arrive un mauvais souvenir : l’éloignement vers un futur incertain de « Press This« .

A l’occasion de sa toute première version, ce thème enfant de TwentySeventeen le complétait de nouvelles possibilités de personnalisation des e-mails générés par WordPress, d’une page de maintenance cohérente avec son ambiance et de codes d’imbrication dont le style est plus cohérent par rapport à cette ambiance.

La plupart des thèmes #WordPress sont incomplets !

Pour cette nouvelle version (la 1.1.0), Vingt DixSept vous propose de personnaliser des pages qui ne font ni vraiment partie de l’Administration de WordPress ni vraiment partie du « front-end » de votre site. Selon votre configuration de WordPress, leur nombre varie de 1 à 3. Commençons par sa configuration classique : un site unique.

La page wp-login.php

Cette page contient l’interface qui s’affichera pour vos utilisateurs lorsqu’ils souhaitent :

• se connecter,
• s’inscrire (si l’option est active),
• réinitialiser leur mot de passe.

La page de connexion de WordPress

Comme on peut le constater, cette interface ne rappelle en rien la palette des couleurs de TwentySeventeen (puisque par exemple le bouton est de couleur bleue) et se rapproche plus de celle de l’administration. Bien que nous soyons très fiers que notre site soit motorisé par WordPress, il semble étrange que le lien de l’icône soit le site WordPress.org pour les américains et le site WPfr.net pour les français (en passant fr.wordpress.org me paraît plus indiqué ici...). En effet, cela devrait être, comme c’est le cas de la configuration multisite, la page d’accueil du site. D’autant plus que j’ai pu constater que la plupart du temps les utilisateurs ne lisent pas cette page jusqu’au bout et ne trouvent pas le lien « Retour vers nom du site » qui se situe sous le formulaire. Par ailleurs, je ne comprends pas pourquoi dans le cas des codes d’imbrication cette icône WordPress est automatiquement remplacée par l’icône du site (si elle existe) et pas ici ??

Ces trois raisons : couleur, lien de l’icône et icône elle-même motivent la personnalisation proposée par Vingt DixSept depuis la section « Formulaire de connexion » du Customizer. L’idée est d’éviter une rupture trop prononcée de l’ambiance. Et puis comme l’image d’arrière plan dans ce thème et son parent est relativement grande, elle est proposée comme fond de cette page.

La section de personnalisation du formulaire de connexion

Les pages wp-signup.php et wp-activate.php

La configuration multisite utilise bien entendu la page wp-login.php et rajoute ces deux autres pages intermédiaires pour gérer l’inscription et l’activation des utilisateurs et de leurs sites. Si je pense que le mécanisme d’inscription du multisite devrait également être utilisé pour la configuration régulière de WordPress (Pourquoi directement créer un utilisateur avant de s’assurer qu’il existe vraiment ?), je trouve que l’intégration de ces pages dans l’ambiance du thème est particulièrement améliorable pour rester positif (voir ce ticket à propos duquel j’avais proposé un patch il y a 9 mois maintenant).

En quoi consiste cette intégration ? WordPress récupère les gabarits du « header » et du « footer » du thème actif et s’en sert pour encadrer en quelque sorte son formulaire d’inscription ou d’activation.

La page d’inscription d’un réseau Multisite.

Dans TwentySeventeen, l’intégration se révèle problématique. Au delà du fait qu’une requête évitable récupère vos 10 derniers articles pour rien si vous n’avez pas choisi une page statique pour l’accueil de votre site (voir cet autre ticket pour plus d’informations), comme la requête principale n’est surchargée que pour éviter une page 404, la page reste définie comme étant une page d’accueil.
Or dans la page d’accueil, TwentySeventeen utilise la version étendue de l’image d’arrière plan. De plus un lien en forme de flèche pour descendre subtilement jusqu’au contenu (grâce à jQuery.ScrollTo) est ajouté en bas à droite du haut de page. Aussi, dans le cas de ces deux pages, il n’existe aucune balise dont l’identifiant est content. Ainsi cliquer sur ce lien entraînera une erreur JavaScript.

Par ailleurs, l’intégration prévue par le multisite pose un problème de cohérence vis à vis de la configuration régulière dans laquelle l’action d’inscription est gérée depuis l’interface de sa page wp-login.php.

La page d’inscription d’un réseau Multisite utilisant Vingt DixSept comme thème pour son site principal.

Voilà pourquoi Vingt DixSept, en plus d’apporter une personnalisation de ces pages intermédiaires depuis le Customizer, homogénéise leur présentation et ce quelque soit la configuration de WordPress.

La mise à jour manuelle d’une extension WordPress est une opération qui n’est toujours pas possible dans le logiciel qui motorise un peu moins de 3 sites Internet sur 10 à ce jour. La feuille de route de l’imminente version 4.9 l’avait intégrée mais faute d’énergie contributive, cette fonctionnalité qui peut paraître basique a été repoussée au jalon 5.0.

Bien entendu, il existe probablement des extensions sur le répertoire officiel des extensions qui comblent cette lacune. Toutefois, il peut paraître étrange qu’un logiciel capable de mettre à jour automatiquement ses versions mineures et semi-automatiquement ses versions majeures et les extensions de son parc n’intègre pas 15 ans après sa naissance cette fonctionnalité d’apparence beaucoup plus simple.

Aussi, étant donné que le principal objet de l’Entrepôt est de simplifier l’installation et la mise à jour des extensions WordPress que j’héberge sur GitHub.com (et de celles de ceux qui veulent m’y rejoindre, comme l’ami Thomas), j’ai pensé que je ne pouvais pas ignorer ce besoin si basique d’autant que j’y avais déjà été confronté en 2011.

Une gestion des versions de toutes vos extensions WordPress grâce à l’Entrepôt.

Alors que la plupart du temps, c’est en oeuvrant sur mes extensions que je trouve des anomalies ou des améliorations possibles et que je propose des patchs aux core committers du projet WordPress, cette fois-ci, j’ai fait l’inverse. J’ai d’abord contribué au ticket #9757 avant d’intégrer une fonctionnalité équivalente dans l’Entrepôt.

Je crois que plus qu’un dispositif manuel de mise à jour des extensions WordPress, les utilisateurs ont besoin de disposer d’une maîtrise simplifiée des versions de ces dernières. Bien sûr ils doivent pouvoir mettre à niveau une version, il me semble également important de leur laisser la possibilité de rétrograder.

En effet, l’abandon d’une fonctionnalité ou encore son exclusion vers une autre extension (c’est arrivé dans la 4.9 !) ou encore le légendaire « Your upgrade broke my theme » sont trois exemples de cas de figure, pour lesquels il me semble raisonnable qu’un utilisateur puisse faire marche arrière pour se donner un temps supplémentaire d’adaptation. Attention toutefois à ne pas s’éterniser, je vous recommande de mettre à jour au plus tôt pour des raisons de sécurité évidente.

L’interface de gestion des versions de vos extensions.

Voilà pourquoi dans la 1.2.0 de l’Entrepôt, une interface accessible depuis un nouveau sous menu du menu des Extensions de l’administration de WordPress simplifiera la gestion des versions de vos extensions. J’utilise le futur car il vous faudra attendre la publication de la 4.9 de WordPress pour en profiter pleinement (j’utilise un JavaScript très utile qui y sera introduit : api-request.js).

Des restrictions sur l’éditeur du code des extensions de WordPress pour le cantonner à une utilisation plus appropriée.

La version 4.9 de WordPress embarquera des améliorations de sa fonctionnalité d’édition « à chaud » du code source des extensions installées sur votre site WordPress. Le maintien de cette fonctionnalité qui a cristallisé pas mal de controverses se justifierait par son pouvoir de transformer les utilisateurs WordPress en « développeurs WordPress« .

Abracadabra!

Il y a effectivement une amélioration. Désormais lorsqu’un utilisateur WordPress voudra éditer le code source d’une extension il verra ce message tant qu’il n’aura pas cliquer sur « Je comprends ».

Je souhaite de tout mon coeur que beaucoup d’utilisateurs, grâce à ce message magique, se découvre une vocation de « développeurs » et contribuent à leur tour au maintien de WordPress et de ses extensions.

Tout ce qui est écrit dans le premier paragraphe est intéressant, je me permets simplement de rajouter une mise en garde supplémentaire par rapport à la notion de perte des modifications apportées suite à l’application des mises à jour. Malheureusement, certains ont leur instinct de conservation qui refait surface et donc pour faire survivre absolument leurs magnifiques modifications, ils décident de ne plus appliquer ces fameuses mises à jour. Résultat, ils augmentent énormément leur vulnérabilité en matière de sécurité. C’est une erreur : mettez à jour au plus tôt et ce d’autant plus si c’est une mise à jour de sécurité.

D’autre part, il me semble qu’une des particularités majeures d’un « développeur WordPress » est d’utiliser la Plugin API à la fois pour permettre la personnalisation de ses oeuvres mais aussi pour étendre celles des autres. Et pour le coup on n’a pas besoin de modifier le code source des autres grâce à elle! Il est regrettable qu’il n’en soit pas question ici.

Selon moi, en l’état*, cette fonctionnalité n’est approprié que dans un seul cas : la possibilité d’éditer les fichiers de personnalisation que certaines extensions utilisent (ex: bp-custom.php pour BuddyPress permet de définir des constantes ou des hooks spécifiques à cette extension) ou la possibilité d’éditer les extensions créés par l’utilisateur (devenu développeur!) pour répondre au même besoin de personnalisation.

Illustration du marqueur à intégrer pour autoriser les modifications à chaud.

Voilà pourquoi la 1.2.0 de l’Entrepôt restreindra l’édition aux seules extensions ou fichiers de personnalisation intégrant ce marqueur d’entête spécifique /* Allow File Edits: true */. L’exception qui confirme cette règle est « Hello Dolly », vous pourrez toujours l’éditer

* Idéalement, cet éditeur devrait permettre, grâce au dispositif de comparaison intégré aux révisions des articles, de constituer des patchs pour faciliter la contribution et le support.

Deux nouvelles extensions BuddyPress rejoignent l’Entrepôt !

Bienvenue aux petits nouveaux!

Vous utilisez « Alternative Public Group Control » ou « Profil de Groupes » ? Si oui vous pourrez dormir sur vos deux oreilles et profiter des notifications de mise à jour et de la simplification de leur application grâce à l’Entrepôt.

De nouveaux liens pour informer sur vos extensions référencées dans l’Entrepôt.

Aux différents endroits où sont listées les extensions de l’Entrepôt dans l’Administration de WordPress, cliquer sur le lien « Afficher les détails » permet de charger le fichier README.md de l’extension dans une nouvelle fenêtre modale. Cette modale intégrera désormais de nouveaux liens paramétrables depuis le JSON de l’extension afin d’informer sur :

• l’historique des versions,
• le dispositif disponible pour récompenser l’auteur d’éventuelles donations,
• le wiki de votre extension

Si vous êtes un auteur d’extensions hébergées sur GitHub (et pas sur WordPress.org), et que vous souhaitez simplifier la vie de vos fidèles utilisateurs, voici comment rejoindre l’Entrepôt.

Restez à jour !

Chers utilisateurs, si vous avez déjà installé l’Entrepôt, vous devriez recevoir la notification de la disponibilité de la 1.2.0 dans votre administration WordPress. Vous ne l’utilisez pas encore ?? Ruez-vous sur son lien de téléchargement ‍♀️

En route pour la version 1.3.0 !

Pour ce prochain jalon majeur, je prévois de m’intéresser aux thèmes. J’ai en effet dernièrement créer un thème enfant de TwentySeventeen et nos thèmes sur GitHub méritent aussi de s’installer et se mettre à jour beaucoup plus facilement. Il parait que la version 4.9 de WordPress facilite la mise en place de sources alternatives au répertoire officiel des thèmes de WordPress depuis le Customizer, ça tombe bien !

Voici une version de maintenance pour votre bibliothèque de media d’utilisateurs préférée ! Elle a été testée sur la prochaine version de WordPress (4.9), vous pourrez donc profiter des améliorations apportées par l’équipe des core committers l’esprit tranquille (en tout cas concernant le bon comportement de cette extension).

Remerciements

Merci à Julien Maury qui est le premier contributeur de MediaThèque. C’est toujours un plaisir de bénéficier des apports de la communauté WordPress, n’hésitez pas à l’imiter en proposant vos « PR » sur le dépôt GitHub de l’extension.

Les corrections / améliorations de cette 1.0.1

• Amélioration de la performance de la requête chargée de supprimer tous les media d’un utilisateur.
• Amélioration du balisage HTML du réglage des types de fichier.
• Correction de la barre de navigation principale de l’interface JavaScript afin de prévoir la non disponibilité du statut Public des media d’utilisateurs.

Mettez vos WordPress à jour !

MediaThèque est une des extensions de l’Entrepôt. Si vous avez la bonne idée de faire confiance à cette source alternative d’extensions, vous serez automatiquement informé de la disponibilité de cette mise à jour dans votre WordPress et pourrez la déclencher en un clic !

Pour ceux qui n’ont pas encore l’Entrepôt, vous pouvez bien entendu mettre à jour manuellement l’extension.

Les nombreux utilisateurs de Gutenberg, le prochain éditeur de texte WordPress pour vos contenus, sont ravis ! Ils peuvent désormais utiliser leur mediathèque personnelle grâce au tout nouveau bloc introduit dans cette nouvelle 1.1.0.

Le bloc Gutenberg de MediaThéque.

Le sélecteur de type de bloc de Gutenberg

Une fois dans l’éditeur qui passionne notre communauté, vous retrouverez votre mediathèque personnelle au sein des blocs communs (« common blocks »). Il vous suffit de cliquer sur son tout nouvel icône (j’en reparle plus bas!) pour commencer l’insertion de votre media d’utilisateur.

Le bouton d’insertion de media personnels

Grâce au bouton « Insérer un Media d’utilisateur » qui est apparu en plein centre du bloc, vous pourrez retrouver l’interface d’ajout et de sélection des media adapté à votre MediaThèque.

La fenêtre de sélection des media personnels

Sélectionnez le fichier que vous souhaitez intégrer à votre magnifique contenu, cliquez sur le bouton « Insérer dans le contenu » pour le retrouver dans votre bloc Gutenberg.

Et toc l’image est dans le bloc

Si vous souhaitez modifier l’apparence d’un media public, vous constaterez que lorsque votre bloc est actif, une icône en forme de crayon s’invite dans la barre de menu supérieure (suivez la flèche bleue de la capture ci-dessus). En cliquant dessus, vous ouvrirez l’interface de définition des préférences d’affichage pour ce media.

Personnaliser vos préférences d’affichage du media

Après un petit coup de centrage, de changement de taille et de lien, cliquez sur le bouton « Définir » de cette fenêtre pour appliquer ces préférences au media inséré dans le bloc Gutenberg.

Apparence de l’affichage du media modifié.

Si vous avez inséré un media personnel privé (qui pour mémoire ne sera visible et téléchargeable que par les utilisateurs authentifiés sur votre site WordPress), vous pourrez éventuellement modifier son alignement depuis ses réglages de bloc.

Accès aux réglages de bloc d’un media personnel privé

MediaThèque change son logo

Afin de mieux s’intégrer dans l’ambiance des icônes de Gutenberg et pour mieux évoquer sa principale caractéristique, le nouveau logo de MediaThèque se base sur l’icône utilisée par WordPress pour l’accès à l’administration des media. Il s’en distingue par l’intégration d’un corps d’utilisateur, l’objectif de l’appareil photo représentant également la tête de l’utilisateur.

Le nouveau logo de MediaThèque.

Je vous rappelle qu’avec MediaThèque, vos utilisateurs disposent d’une bibliothèque de media personnalisée.

Mettez à jour vos MediaThèques !

Vous faites confiance à l’Entrepôt, magnifique ! Allez directement dans votre Administration WordPress et vous pourrez déclencher directement cette mise à jour ou son installation en quelques clics. Autrement, vous pouvez le faire à la mimine en téléchargeant la version 1.1.0 depuis le lien ci-après.

2.7, c’est la version majeure qu’avait atteint le projet open source WordPress lorsqu’on s’est rencontré pour la première fois. Si énormément de chose ont évolué depuis, un élément a fondamentalement très peu varié : l’éditeur de texte mis à notre disposition pour rédiger nos contenus. Après 9 années de pratique, on développe une impression d’immuabilité et tellement d’habitudes que la perspective de devoir tout remettre à plat peut générer quelques inquiétudes.

Cette perspective approche, elle est prévue pour la version 5.0 de WordPress, sa toute prochaine. Alors, tenons-nous prêts !

Le projet Gutenberg

Rappelons-nous : l’histoire commence en décembre 2016, lorsque Matt Mullenweg oriente les développements du Core sur trois axes : la Rest API, le Customizer et l’éditeur.

Crédits WordPress.org

On découvre alors l’approche retenue pour faire évoluer l’éditeur de texte : le contenu s’organisera en blocs. Deux semaines plus tard Matias Ventura, co-désigné avec Joen Asmussen pour concrétiser cette orientation, publie une revue technique pour cadrer, échanger sur les travaux à réaliser et fixer un rendez-vous hebdomadaire sur le Slack de WordPress.

Le 17 juin 2017, à l’occasion d’une séance de questions/réponses avec Matt Mullenweg lors du WordCamp Europe, nous assistons à une première démonstration des travaux accomplis sur le prochain éditeur et apprenons sa mise à disposition sur le répertoire officiel des extensions de WordPress.

Il s’appelle Gutenberg en référence à l’imprimeur allemand qui révolutionna son domaine en inventant les caractères métalliques mobiles.

Gutenberg révolutionne WordPress

Comme l’illustre la démonstration de Matias lors du récent WordCamp US, Gutenberg et son approche basée sur les blocs de contenu modifient radicalement la manière dont on écrit dans WordPress.

Comme toute rupture, ce changement s’accompagne de craintes au sein de la communauté. J’ai moi-même été très inquiet lors de l’épisode qui a entouré le changement de licence de la librairie React. Gutenberg s’appuie sur cette dernière pour générer ses interfaces utilisateur.

D’abord le fait que cette librairie soit un projet « gouverné » par l’organisation Facebook Open Source ne me met toujours pas à l’aise. Ensuite, l’investissement en temps dans l’apprentissage de cette nouvelle librairie m’inquiétait au point de me faire remettre à toujours plus tard un intérêt quelconque pour cet éditeur.

Et puis il y a eu la décision d’équiper tous les sites WordCamp de Gutenberg. L’idée étant bien entendu de multiplier les cas d’usage de l’éditeur pour l’éprouver. C’est à ce moment là que j’ai eu un déclic. En tant que contributeur du WordCamp de Paris en particulier et de WordPress en général, je me devais de montrer l’exemple en surmontant mes réserves dans l’intérêt du projet (et donc dans notre intérêt à tous!).

Depuis le 11 octobre 2017 et la publication de cet article, j’ai complètement switché sur Gutenberg et je dois avouer que l’expérience m’a très vite séduit et a attisé ma curiosité.

J’ai alors entrepris de créer un « GutenBlock » (un bloc Gutenberg) pour l’extension MediaThèque. Ce qui m’a permis de découvrir l’API des Blocks grâce à la documentation sur Gutenberg et l’article de Riad, un des membres de l’équipe de développement de Gutenberg. Cette entreprise m’a complètement rassuré sur le fait que l’investissement dans l’apprentissage de React n’est pas nécessaire pour pouvoir enrichir et profiter des apports de Gutenberg depuis une extension. J’en profite pour chaleureusement féliciter Matias et son équipe pour le super taf accompli jusqu’à présent.

L’accompagnement de Gutenberg

Crédits WordPress.org

Dans son State of the Word 2017, Matt indique, au delà des itérations du code de Gutenberg, les domaines sur lesquels il faut encore s’investir. La documentation du projet, bien entendu, mais aussi l’accompagnement des utilisateurs grâce notamment aux échanges qui peuvent s’organiser à l’occasion des meetups ou des WordCamps.

Je salue l’initiative de la communauté WordPress de Nantes qui a consacré son meetup du 30 octobre à Gutenberg et j’espère qu’elle sera imitée par le plus grand nombre de groupes meetup. J’espère également que les WordCamps à venir proposerons des contenus liés à l’utilisation et l’extension du prochain éditeur de WordPress.

Il subsiste de nombreuses réserves quant à la révolution qui est en marche et plus grave, selon moi, le relai positif par les membres de notre communauté est encore trop timide alors que nous sommes à un cycle de développement du Core de l’arrivée de Gutenberg dans nos sites WordPress. J’en profite pour féliciter JB, Julio, et Julien respectivement pour leurs articles et son tutoriel sur le sujet qui nous intéresse au plus haut point.

En passant, pour les fans de Slack, il existe aussi une chaîne dédiée à Gutenberg sur WordPress-fr dans laquelle des discussions très intéressantes interviennent.

Traduction de la page « About » de Gutenberg

Pour tous ceux qui se demandent par où commencer ou qui se pose des questions sur les impacts de cette révolution, une page spécifique est disponible sur WordPress.org pour vous guider.

Vous pouvez consulter et contribuer à ma proposition de sa traduction française.

En détournant le proverbe « en faisant, on apprend », j’ai eu envie de nous rappeler que la contribution à un projet open source en général et à WordPress en particulier nécessite d'abord de faire.

Rassurons-nous : la contribution n’est pas réservée aux élites ou aux stars du développement : tout le monde peut et devrait choisir ce mode d’expression pour régler les difficultés ou les nouveaux challenges d’un projet.

Ça ne se commande pas !

Nous sommes irrésistiblement entraînés vers la satisfaction d’attentes que nous partageons (entièrement ou partiellement) avec le projet. Cette envie de contribuer apparaît généralement lorsque le projet présente une anomalie ou un manque dont la résolution ou le comblement lui (et donc nous) sera bénéfique.

Ça ne se rémunère pas !

Il s’agit bien d’un don, d’un apport personnel au profit du projet qui se gratifie par la reconnaissance, l’apprentissage de nouveaux savoirs, l’acquisition de nouvelles compétences et l’accumulation d’expériences inédites.

Ne vous demandez pas ce que votre pays peut faire pour vous, mais plutôt ce que vous pouvez faire pour votre pays.

John F. Kennedy, 20 janvier 1961.

Je suis fier d’être un contributeur du projet open source WordPress et de constamment me poser cette question en remplaçant “pays” par “WordPress” !

WordPress Core.

Depuis septembre 2014, mon environnement de création d’extensions se base sur le “trunk” (version de développement) de WordPress. Je reste ainsi au plus proche des évolutions introduites pour en profiter très tôt et identifier les éventuelles adaptations à réaliser sur mes extensions pour les maintenir dans le temps. Par ailleurs, je me fais un devoir de participer aux phases “bêta” qui précèdent la publication des versions majeures.

• Benny (4.0)
• Dinah (4.1)
• Powell (4.2)
• Billie (4.3)
• Clifford (4.4)
• Coleman (4.5)
• Pepper (4.6)
• Vaughan (4.7)
• Evans (4.8)
• Tipton (4.9)

Sur chacune de ces versions, j’ai proposé au moins un patch qui s’est matérialisé par un commit. Ce qui m’a valu de recevoir des “props” et d’être listé dans l’équipe des contributeurs du Core.

BuddyPress Core.

Depuis le 2 janvier 2014, je suis membre de l’équipe de développement de l’extension BuddyPress. J’ai considérablement enrichi mon savoir-faire en contribuant à ce projet et en cotoyant les membres de son équipe.

D’abord j’ai pu me rendre compte de l’importance du respect des standards d’écriture du code de WordPress, de la documentation du code en particulier et de la rédaction de guides d’utilisation / d’extension plus généralement.

J’ai également compris comment les tests unitaires pouvaient nous faire gagner du temps dans la maintenance du code et, surtout, j’ai appris à les mettre en oeuvre pour toute extension WordPress.

J’ai amélioré ma maîtrise de JavaScript en me plongeant dans l’API des media de WordPress pour participer à l’élaboration de celle de BuddyPress. J’ai même profité des connaissances engrangées sur Backbone.js et Underscore.js pour expérimenter de nouvelles interfaces frontales et créer de nouveaux panneaux dans le Customizer afin de simplifier la personnalisation du prochain ensemble de gabarits (Template Packs) de BuddyPress “BP Nouveau”. Cela m’a permis de mesurer l’importance de la Rest API et de ses endpoints pour établir un dialogue beaucoup plus fluide entre l’interface et les données.

J’ai découvert des utilisations de JavaScript « hors du navigateur » grâce à Node.js et certains gestionnaires de tâches, lesquelles (les utilisations) ont dramatiquement accéléré et fiabilisé la génération optimisée de mes packages d’extension.

Ensuite je pratique l’anglais très régulièrement en mettant à profit l’investissement réalisé lors de mes passages au collège et au lycée. Résultat : j’ai développé ma maîtrise écrite et ma compréhension de ce langage.

J’ai également constaté la puissance de l’accueil constructif d’une contribution par rapport à sa critique destructive. Concrètement, on obtient beaucoup plus en remerciant l’effort, en félicitant l’innovation et l’ingéniosité tout en suggérant des adaptations (lorsque c’est nécessaire) plutôt qu’en sanctionnant le contributeur d’une critique.

Enfin, j’ai énormément amélioré mon organisation personnelle et ma capacité à contribuer à de nouveaux projets en me familiarisant avec Git. C’est depuis un bon moment maintenant mon plus fidèle compagnon et je vous recommande vivement son utilisation si toutefois vous n’avez toujours pas mis le nez dedans !

WordCamps.

J’ai fait la connaissance avec ces rencontres communautaires en 2013. J’étais un des orateurs de l’évènement. Bien que je sois loin d’être à l’aise dans cet exercice, j’ai contribué aux contenus de cet évènement, de son édition 2014, du premier WordCamp Lyon, du premier BuddyCamp Brighton, du premier WordCamp Antwerp et j’ai assuré le “back-up” d’un intervenant lors du WordCamp Paris 2016.

À l’occasion de son édition 2016, j’ai rejoint l’équipe d’organisation du WordCamp parisien et ai découvert une expérience à la fois très particulière et très proche du travail d’équipe que je connais avec le projet BuddyPress. Je préciserai cette particularité dans quelques lignes.

Cette édition fut une réussite et surtout un formidable tremplin pour appuyer la candidature de Paris à l’organisation du WordCamp Europe 2017. Comme vous le savez aujourd’hui, Paris a effectivement été le théâtre de ce WordCamp plus régional (voir continental !). J’ai fait partie de deux équipes : l’équipe locale chargée de faciliter les relations sur place et les aspects logistiques, ainsi que l’équipe communautaire chargée d’organiser deux évènements qui ont précédés le WCEU. Le premier était le sommet communautaire, auquel j’ai par ailleurs eu la chance de participer, et le deuxième était le jour des contributeurs. Je me suis tout particulièrement investi dans ce second évènement et j’ai énormément appris de cette fabuleuse expérience. Mon intérêt pour la contribution au code du projet open source WordPress était un facteur supplémentaire de motivation pour moi et je me suis très vite pris au jeu.

Aussi, lorsqu’on m’a proposé d’allumer la mèche d’une nouvelle bougie du WordCamp Paris, super confiant suite à la réussite de ce jour des contributeurs, je n’ai pas reculé devant ce nouveau défi pour 2018 ! L’expérience du WCEU 2017 et plus particulièrement ma réflexion sur les moteurs qui m’avaient fait m’investir ont guidé et guide toujours mon approche de la coordination d’une équipe d’organisation d’un WordCamp. Il est encore un peu tôt pour tirer un bilan de cette application plus locale, mais j’ai d’ores et déjà pu mesurer qu’on ne conduit pas un tel projet comme j’ai l’habitude de le faire dans ma vie professionnelle. C’est beaucoup plus complexe et exigeant du fait d’une particularité essentielle : il s’agit d’une équipe de contributeurs (bénévoles) et comme je l’ai dit en introduction : la contribution ne se commande pas ! C’est aussi largement plus passionnant et enrichissant que la conduite de projets professionnels, je vous propose d’en reparler à la mi-mars pour un bilan plus précis de cette expérience toujours en cours.

Gutenberg : la route prioritaire pour 2018.

Toute cette argumentation sur les bénéfices communs de nos contributions (à l’aide d’exemples de ce que m’ont apporté les miennes) me permet de vous sensibiliser, une fois encore, sur Gutenberg.

Pour rappel : cette révolution qui s’est mise en marche à la mi-janvier 2017 concerne notre manière de publier des contenus sur nos sites WordPress. Après 12 années d’évolutions lentes et progressives de l’éditeur de texte, une innovation de rupture se présente à lui et nous nous devons de concentrer notre énergie pour l’accompagner du mieux que nous pouvons dans l’intérêt du projet open source WordPress, et donc dans notre propre intérêt.

Des contributions facilitées.

Comme le développement de Gutenberg intervient sur GitHub, cela simplifie énormément les échanges des contributeurs permettant une accélération sensible des cycles de développement et de publication des versions.

En effet, même si des petits pas ont été réalisés par le Core de WordPress et de BuddyPress en mettant à disposition des dépôts Git synchronisés avec les dépôts SVN officiels (en lecture seule), l’organisation de la contribution au code et celle des échanges des contributeurs pour ces deux projets nécessite encore des efforts de simplification (pour rester positif).

L’utilisation des environnements « trac » est relativement fastidieuse. Elle oblige à transmettre des fichiers .diff ou .patch pour montrer nos propositions d’évolution ou de correction. Les discussions qui s’ensuivent nécessitent de faire référence à des numéros de ligne ou noms de fonction, voire à copier/coller en commentaire certaines parties de ces fichiers. C’est relativement lourd.

En choisissant GitHub, le projet Gutenberg s’ouvre encore plus aux nouvelles contributions en profitant des fonctionnalités des « pull requests » (PR), des services d’intégration continue (ex: vérification de l’application des standards de code WordPress, ou encore des tests unitaires pour PHP et React) et de revues de ces PR lesquelles autorisent l’insertion de commentaires directement dans la représentation du code modifié. La praticité ainsi que les gains de temps et d’efficacité sont énormes !

Pour preuve, vous pouvez vous amuser à parcourir mes discussions avec deux membres de l’équipe du projet au sein de cette PR qui a été intégrée au code de Gutenberg (comme illustré ci-dessus).

Le défi communautaire.

D’abord, je trouve que l’équipe du projet Gutenberg a fait d’énormes efforts d’explication et de documentation comparativement à ce qui se fait généralement pour le Core de WordPress.

Si le calendrier d’intégration de Gutenberg au Core de WordPress peut paraître ambitieux (c’est prévu pour la prochaine version majeure), je pense qu’il demeure raisonnable pour la partie technique. Je suis convaincu que le nombre de contributeurs au code de Gutenberg va augmenter exponentiellement au fur et à mesure que les éditeurs d’extensions populaires investiront le sujet.

S’agissant de l’accompagnement du changement pour les utilisateurs, il reste vraisemblablement des efforts à faire en matière de sensibilisation. J’y vois personnellement un fabuleux challenge pour la communauté des contributeurs WordPress dont nous faisons tous partie.

Nous pouvons être un accélérateur efficace dans ce domaine :

• grâce aux groupes meetup existants en France il est possible d’organiser des tests d’utilisation ou des ateliers de manipulation.
• Lors des WordCamps, les conférences et les ateliers dédiés au sujet ainsi que leur relai vidéo sur WordPress TV apporterons des éclairages et des partages d’expérience précieux.
• Le site fr.WordPress.org peut concourir à une meilleure appropriation des avancées introduites par Gutenberg en poursuivant l’effort de traduction des ressources documentaires initié dernièrement.
• Les blogs ou sites spécialisés sur WordPress, en particulier ceux dont les flux apparaîssent dans le widget des tableaux de bord de nos sites WordPress, doivent aborder le sujet objectivement et enfin proposer des tutoriels ou astuces d’utilisation.

De mon côté, j’ai déjà totalement basculé sur Gutenberg : ce site l’utilise et j’ai mis à jour mon environnement de développement pour l’y intégrer également. En l’utilisant, non seulement je profite de toutes les avancées et des gains de temps qu’il introduit par rapport à l’éditeur classique, mais en plus j’identifie plus facilement les contributions possibles (j’en ai même déjà soumis quelques unes !) ainsi que les adaptations qu’il me reste à faire pour certaines de mes extensions.

On se retrouve l’année prochaine, pour de nouvelles contributions ! Excellentes fêtes de fin d’année à toutes et tous

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 🙂

GutenBlocks

Requiert Gutenberg
Requiert WordPress 4.9

3 téléchargements

Afficher la page GitHub de la version

Télécharger la version 1.1.0