Le 8 février dernier, WP Paris organisait un Meetup dédié à Gutenberg et j’ai eu l’honneur de faire (re)découvrir à la soixante-dixaine de courageux qui avaient bravé des conditions météorologiques défavorables l’éditeur moderne.

Qui a entendu parler de Gutenberg ?

Qui est inquiet à son sujet ?

C’est avec ces deux questions que j’ai commencé mon propos. Elles ont, d’ailleurs, reçu à peu près le même nombre de mains levées. Deux raisons semblent expliquer la réserve vis à vis de la première phase du projet Gutenberg.

D’abord comme le titre le premier « slide » de mon diaporama, l’arrivée de l’éditeur moderne dans le « Core » de WordPress met fin à plus de 10 ans de stabilité de notre expérience de publication d’articles, de pages et de tout autre type de contenu.

Ensuite, pour certains des participants, l’éditeur moderne : c’est aussi la remise en cause des dispositifs qu’ils avaient mis en place à l’aide d’extensions pour simplifier, sécuriser et améliorer la prise en main par leurs clients des développements ou intégrations entrepris pour leurs comptes.

« Ça va bien se passer ! »

Rassurer, c’est l’objectif principal que je m’étais fixé lors de la préparation de mon intervention. J’ai alors pensé que la meilleure manière de transmettre ma confiance dans l’éditeur moderne était de l’utiliser comme support pour sa présentation. L’écran d’édition de mon type de contenu spécifique s’est donc transformé en visionneuse de « slides », le temps du meetup.

Pour me simplifier le passage d’un « slide » à l’autre, j’ai simplement créé un nouveau bloc Gutenberg dont le rôle est d’insérer une pagination vers le lien d’édition de mon précédent et/ou suivant type de contenu. Les caractéristiques du type de contenu hiérarchique ont fait le reste (notamment la possibilité de définir l’ordre ou des rattachements parent).

En plus comme j’avais prévu de démontrer l’éditeur moderne, ce choix s’est révélé très pratique, le moment venu .

Si vous aussi, vous souhaitez profiter de ce bloc pour vos présentations, vous pouvez le récupérer depuis son répertoire sur GitHub.com (les français pourront même importer mes slides).

GutenPrez

Afficher la page GitHub de la version

Télécharger la version 1.0.1

Standardisation, modernité et maîtrise.

J’ai beaucoup insisté sur ces trois points lors de mon intervention.

Premièrement, le choix du projet Gutenberg concernant la persistance des blocs de contenu apportera selon moi une standardisation qui sera très bénéfique aux prochaines fonctionnalités dérivées.

Deuxièmement, baser l’interface de l’éditeur du projet Gutenberg sur un JavaScript moderne et exposer une API qui ne requiert pas de connaissances spécifiques dans la librairie choisie (React) améliore non seulement l’expérience des utilisateurs mais aussi celle des créateurs d’extensions.

Troisièmement, la possibilité d’attacher une combinaison de blocs aux types de contenu grâce à la propriété template de l’objet WP_Post_Type permet d’orienter la rédaction de l’utilisateur d’une manière beaucoup plus intuitive et performante que le recours aux metaboxes et meta données de contenu. Nous disposons même d’un contrôle affiné quant à l’insertion de blocs ou à leur réorganisation grâce à la propriété template_lock du même objet.

Le récapitulatif

Lors de notre meetup, nous avons échangé sur pas mal d’autres points comme la possibilité de garder l’éditeur classique une fois la version 5.0 de WordPress publiée, la réutilisation des blocs ou encore les fonctionnalités contrôlables depuis le thème grâce à la fonction add_theme_support. Si vous souhaitez approfondir le sujet, je vous invite à parcourir une version améliorée des notes que j’avais préparées pour ce meetup.

Maintenant que le bilan officiel de cette édition anniversaire est publié, je peux vous parler plus personnellement de mon expérience en tant que coordinateur de son organisation. Je vous l’avais promis à la fin décembre 2017 : je tiens cette promesse avec quelques jours de retard

Il semble important de préciser que les mots qui vont suivre n’engagent que moi, je le précise car j’ai pu constater que parfois certain·e·s n’arrivaient pas à faire la part des choses…

L’organisation centrale des WordCamps l’appelle « organisateur primaire », certains parlent de « lead orga », de mon coté, je préfère envisager le rôle que j’ai tenu dans l’organisation de ce WordCamp comme celui qui coordonne une équipe de contributeurs en essayant d’y maintenir une bonne harmonie et une certaine efficacité.

Dans le détail, c’est celui ou celle qui :

• allume la mèche en soumettant l’application,
• propose un positionnement pour l’édition de la rencontre communautaire,
• définit la taille de la flamme lors du cadrage budgétaire avec l’organisation centrale des WordCamps,
• assure l’interface avec les députés communautaires de l’organisation centrale des WordCamps,
• constitue l’équipe des contributeurs de l’organisation et lui propose les règles du jeu pour leur collaboration,
• donne l’exemple en prenant un ou plusieurs domaines de l’organisation en charge (je me suis chargé de la gestion du lieu en duo avec Eric et du budget du WordCamp),
• entretient cette flamme pendant la phase de préparation en franchissant une série de jalons,
• transmet aux organisateurs les questions/commentaires issus du site Web du WordCamp qui les concernent ou y répond directement.
• tente de faire briller la flamme le plus intensément possible le jour J tout en veillant à ce qu’elle ne brûle pas les différentes équipes du rassemblement !

Tenter d’orienter le positionnement d’un WordCamp.

Je prends volontairement une double précaution car je me rappelle de ce que mes études m’ont appris sur ce sujet. On a beau vouloir imprimer notre vision d’un produit (ou d’un événement dans notre cas), on peut même multiplier sa communication : ce sont quoiqu’il arrive les consommateurs qui la définissent.

Si j’avais, depuis 2015 et après 3 participations au WordCamp de Paris, déterminé mes attentes à propos d’un tel rassemblement, ma participation au sommet communautaire de WordPress en 2017 m’a permis de bénéficier d’éclairages, de points de vue et d’un aparté avec Jenny durant une pause très instructifs pour confirmer ou infirmer chacune de ces attentes. Je me suis notamment aperçu que ma vision et mes espoirs quant aux résultats d’un WordCamp étaient très proches de ceux de l’organisation centrale des WordCamps.

En résumé, je crois qu’il y a principalement deux tendances pour installer l’identité d’un WordCamp : celle du spectaculaire ou celle du communautaire. Chacune d’entre elles a ses avantages et ses inconvénients. Je suis naturellement beaucoup plus attiré par la seconde.

Le 15 juin 2017, j’ai assisté à la concrétisation du premier évènement auquel j’ai contribué de manière très significative aux côtés de Rocío : le « contributors day » du WordCamp Europe. Il a réunit 500 contributeurs répartis sur les 2 étages du business center des docks de Paris (mes rotules s’en souviennent encore !). Ce format de rencontre est vraiment, et de loin, mon préféré.

Comme je l’écris dans l’article ci-dessus, c’est « imho » le format qui permet d’apprendre le plus vite au sujet de WordPress et de l’ensemble de ses domaines. Les deux jours suivants, j’ai bien entendu assisté à certaines conférences du WordCamp Europe mais j’ai surtout guidé une micro équipe constituée de 2 jeunes techniciens de Seekat pour la mise en place, le suivi et la résolution de problèmes en lien avec le raccordement filaire et wifi à Internet du WordCamp Europe et de son After Party.

WordPress Paris

Paris, FR
972 wapuu

L’objectif de ce groupe est de créer un évènement mensuel regroupant les amoureux de WordPress sur la région Ile-de-France, pour échanger nos bonnes pratiques, nouveautés, obt…

Next Meetup

Partages d’expérience sur des business models WordPress

Monday, Apr 16, 2018, 6:30 PM
80 Attending

Check out this Meetup Group →

Ma participation régulière aux rencontres du groupe WordPress d’Ile de France m’a également permis d’écouter les retours d’expérience de ses membres vis à vis du gigantisme du WordCamp Europe et de me rendre compte de leurs aspirations à un dosage plus important des aspects communautaires, de proximité et d’intimité pour notre rencontre annuelle. Si un WordCamp est très ouvert et accueille toute personne quelque soient son origine et ses différences, les membres de ce groupe représentent, selon moi, son cœur de cible.

Même si j’avais une furieuse envie d’intégrer une journée des contributeurs au WordCamp Paris 2018, je dois avouer que j’ai douté de son potentiel succès auprès des participants de cette rencontre (seuls 52 français ont participé à celui du WCEU 2017 : cette statistique m’a vraiment refroidit d’autant que le nombre de franciliens a forcément été inférieur). Je l’ai donc écarté pour l’édition 2018.

Enfin, je savais que 2018 venait après 2017 et surtout 2016. Le WordCamp Paris 2016 s’était déroulé dans un lieu somptueux à la fois pour les participants et les sponsors : cette référence nous serait rappelée par ces deux populations quoique nous échafaudions pour 2018.

J’ai donc pensé que m’appuyer sur les suggestions émises lors de son enquête de satisfaction serait intéressant pour l’évènement que nous avions à dessiner pour 2018. D’ailleurs, si vous les relisez vous vous apercevrez que certains moments de notre WordCamp ont tenté de les mettre en oeuvre.

Voici donc le cheminement du positionnement 2018 du WordCamp de Paris : une rencontre communautaire dédiée à WordPress pour apprendre, approfondir, contribuer et s’amuser ensemble. Cerise sur le gâteau, 2018 marquait 10 années de WordCamps à Paris : ça se fête !

La quête du lieu du WordCamp.

Vu de ma fenêtre le lieu est accessoire, ce qui importe le plus à mes yeux c’est notre volonté de nous rassembler pour contribuer à WordPress. Or tout au long de l’année : on le fait, la plupart du temps, à distance grâce à Internet et à la multitude d’outils collaboratifs ou de mise en relation qui existent. Le simple fait de se retrouver « IRL » une fois par an constitue un premier apport d’intensité formidable.

Tou-te-fois, le choix du lieu est une étape très importante pour un WordCamp. C’est lui qui validera la ou les dates ainsi que les horaires de l’événement, le nombre de personnes qu’il pourra accueillir et influera énormément par la suite sur la restauration des participants et les installations mises à la disposition des sponsors (source de financement principale de tout WordCamp).

Fin juillet 2017, lorsque j’ai dû arrêter mon choix, j’ai privilégié la certitude pour compenser les nombreuses zones d’ombre de notre organisation d’alors (l’équipe d’organisation ce n’était que moi et Olivier) car c’était la première fois que j’étais confronté à ce type de décision. Deux lieux restaient dans ma « shortlist » finale : celui de 2016 et celui qui avait accueilli le plus grand nombre de WordCamps Paris de son histoire : la « MAS ». Personnellement, si je n’avais pris que mon confort en ligne de compte, j’aurais choisi celui de 2016 car il est à une vingtaine de minutes à pied d’où j’habite !

J’ai préféré opter pour une certaine cohérence vis à vis du positionnement du WordCamp et de la valeur émotionnelle de la « MAS » qui cadrait mieux avec l’idée d’une célébration communautaire.

Par ailleurs, je n’ai pas souhaité prendre un risque trop important par rapport à notre ambition en nombre de participants. Le WordCamp 2016 a accueilli 418 des 495 personnes qui avaient achetées un billet, le WordCamp Europe 2017 a rassemblé 346 des 480 français qui avaient réservés leur siège. Aussi 250 à 300 personnes, étant donné la pente de la courbe de participation que je viens de tracer, m’a semblé être un objectif raisonnable et atteignable.

La différence de coût locatif entre les deux lieux, étant donné la capacité et la durée visée, était de surcroit fortement favorable au lieu établi dans le 13e arrondissement de Paris. Je l’ai donc choisi.

Formaliser un budget prévisionnel.

A l’issue de mon entretien avec l’organisation centrale des WordCamps, entretien durant lequel notre projet de rencontre communautaire a été validé, il m’a été demandé de travailler sur un budget prévisionnel.

L’intérêt de cet exercice est de profiter de l’expérience du député communautaire de WordPress pour passer en revue les différents postes de dépense que nous devons compenser par des revenus. C’est également le moment où nous recevons un premier revenu : celui du sponsoring global des WordCamps, élément hyper important dans la mesure où il nous permet de couvrir les premières dépenses.

Plus nous disposons d’éléments quant aux contenus du projet de WordCamp, plus notre première approche budgétaire sera cohérente. Je me suis notamment aperçu qu’il était important d’avoir une idée assez précise :

1. du nombre d’interventions et donc d’orateurs (nous pouvons le déduire de la durée en jour(s) du WordCamp, de son amplitude horaire, et du nombre de salles mises à notre disposition par le lieu),
2. de la taille de notre staff (équipe d’organisation et de volontaires le jour de l’évènement),
3. des plans de sponsoring que nous proposons (liste des niveaux, quantité et prix pour chacun d’entre eux),
4. du nombre de participants (étant donné que nous les réunissons à l’occasion des remarques d’ouverture et de clôture dans une même salle : ce nombre coïncide souvent avec la capacité maximale de notre plus grande salle).

Grâce aux combinaisons de ces éléments :

• avec 3. & 4. nous avons une évaluation des recettes locales (sachant que le prix d’une journée de WordCamp est imposée et vaut 20 euros),
• avec 1. & 2. & 3. nous pouvons chiffrer le coût du dîner des orateurs (nombre de personnes pour le staff, les orateurs et les sponsors),
• avec 1., 2., 3. & 4. nous pouvons évaluer les coûts pour la plupart des autres postes de dépense (restauration, badges, t-shirts, soirée de clôture, etc..)

Il faut garder à l’esprit qu’un sponsor, un organisateur, ou un volontaire doivent pouvoir venir et que ce sera autant de billets en moins disponibles à la vente pour les participants. Nous avons également prévu un poste pour la sécurisation de l’accès au lieu de l’évènement, c’est malheureusement devenu un impératif étant données les menaces extérieures auxquelles nous sommes exposés.

Notons que le site Internet du WordCamp propose un outil très bien fait pour enregistrer ce budget prévisionnel, mettre à jour au fur et à mesure le budget « de travail » du WordCamp, facturer les sponsors, payer les fournisseurs et demander des remboursements.

L’équipe des organisateurs.

Sa constitution

Cette année nous avons ouvert pour la première fois la contribution à l’organisation du WordCamp de Paris en publiant un appel à organisateurs. Comme le 3 août 2017, nous n’étions que deux, ça peut paraître logique. Je crois cependant que l’appel à organisateurs devrait être systématisé pour tout WordCamp et ce même si l’équipe d’organisation est déjà constituée.

Je vois plusieurs bonnes raisons de le faire :

• c’est un moyen très pratique pour obtenir l’engagement des organisateurs à respecter la charte des WordCamps ;
• c’est un bon moyen d’intégrer progressivement des personnes motivées car candidates et de profiter de leurs regards neufs car candides ;
• c’est un moyen de couvrir le risque de domaine d’organisation à découvert, si l’un de vos organisateurs est contraint de renoncer à l’aventure en cours de route, grâce à la constitution d’un volant de remplacement ;
• c’est un moyen intéressant de commencer à communiquer sur le positionnement de votre rencontre communautaire lors de la publication de l’appel.

Sa collaboration

Avant toute chose : les organisateurs sont des contributeurs bénévoles qui mettent à la disposition du WordCamp du temps et de l’énergie en plus de leur activité professionnelle et au détriment de leur vie personnelle. Je pense qu’il est important de bien garder cette donnée en tête car cela a plusieurs impacts sur l’organisation de la collaboration :

• la répartition des tâches doit être la plus équitable et cohérente possible,
• la polyvalence et le dépassement du périmètre des rôles doivent être encouragés,
• l’innovation, la prise de risque et l’erreur doivent être acceptés,
• la prise de décisions et d’initiatives doit être soutenue et secondée,
• la transparence et l’accès de tou·te·s à tout doivent être recherchés,
• la valorisation des efforts de chacun·e ainsi que leur remerciement sont essentiels,
• la vigilance sur le respect des jalons est primordiale : en cas de dérapage, il ne faut pas hésiter à proposer notre aide à l’organisateur en difficulté,
• il faut pouvoir continuer à progresser malgré l’indisponibilité de certain·e·s tout en s’assurant qu’ils ou elles pourront se maintenir à jour,
• la critique ou le désaccord doivent s’accompagner de propositions alternatives.

Par ailleurs, plus l’équipe est grande plus il est compliqué de trouver des disponibilités communes pour échanger à l’occasion de « conf calls ». On peut toutefois compenser en mettant en place des outils de discussions asynchrones et en partageant des compte-rendus réguliers.

Pour information, lors de la phase de préparation du WordCamp Paris 2018, nous nous sommes réunis à douze reprises (soit un peu moins de 2 fois par mois). Si à aucun de ces moments conviviaux nous n’avons été au complet : ça ne nous a pas empêché de progresser collectivement. Je note cependant que la période qui correspondait à ma pause déjeuner était la plus propice à maximiser le nombre de participants (et sans doute à s’assurer que je ne sois pas trop bavard !).

Une de ces réunions est très importante : celle du lancement. C’est l’occasion de proposer la manière de collaborer que nous pensons la plus efficace, d’indiquer qui fait quoi, les outils disponibles et de partager le positionnement ainsi que les objectifs du WordCamp.

C’est la réunion que j’ai le plus préparé en formalisant beaucoup d’éléments et notamment des fiches décrivant chacun des rôles d’organisation ainsi que des principes de fonctionnement qui me paraissent fondamentaux :

• chacun·e est autonome sur son domaine et l’arbitre (prend les décisions, fixe les échéances..) ;
• chacun·e est encouragé•e à mettre en commun sur le « P2 » des récapitulatifs réguliers de ses progrès pour nous maintenir informé·e·s et informer notre volant de remplacement * ;
• chacun·e est encouragé·e à rédiger des articles sur le site paris.wordcamp.org pour partager au sujet des travaux accomplis. Nous sommes tou·te·s les administrateur·rices de ce site ;
• notre action ne doit pas être ralentie par la recherche absolue d’un consensus. A l’issue de l’échéance fixée, fin des débats et mise en oeuvre ;
• un certain nombre de guides/outils peuvent nous aider dans nos travaux : les jalons d’un WordCamp, notre description des rôles sur le Google Drive du WordCamp et bien entendu le guide officiel d’organisation d’un WordCamp (en) ;
• chacun·e doit être exemplaire en respectant (et en faisant respecter) le code de conduite et la charte des WordCamps.

*Le « P2 » est un site WordPress utilisant le thème P2 auquel l’équipe d’organisation étendue (incluant le volant de remplacement) avait accès. Je regrette énormément le silence absolu des organisateurs de secours malgré des appels à contributions ou à questions. Si vous êtes un organisateur de ce type et que vous pouvez contribuer de la sorte : faites le. Ce sera un excellent moyen pour vous de démontrer votre intérêt, vos compétences et les organisateurs en place s’en souviendront le moment venu. Je pense également qu’il est intéressant d’associer encore plus de populations à ce type d’outil comme les sponsors et les volontaires pour favoriser la contribution et la richesse des points de vue.

Ses configurations resserrées

Il nous est également arrivé de nous réunir en plus petits comités. Je pense notamment au duo formé par Thomas et Eric pour les travaux de conception et d’impression du badge d’accès du WordCamp ou encore lors de la définition des contenus des plans de sponsoring. Sur ce sujet, après un travail préliminaire de Laurent, nous avons organisé une réunion commune avec Julio et Thierry pour rapidement valider la visibilité de chaque niveau de sponsoring sur le site web, sur le lieu de l’événement et sur celui de l’after party. La publication de l’appel à sponsors est en effet un élément très important de la réussite du WordCamp, cette année nous l’avons ouvert presque 5 mois avant le jour J (contre 3,5 mois en 2016 ou 3 mois en 2015 à titre comparatif), ce qui nous a permis grâce aux réponses de nos partenaires de très rapidement nous rassurer par rapport à la tenue de notre budget préliminaire.

Sa proximité avec l’organisation centrale des WordCamps

Les membres de l’organisation centrale des WordCamps jouent un rôle essentiel dans la réussite des WordCamps. Ils apportent un cadre protecteur, des outils, des conseils et nous libèrent des préoccupations liés à la gestion des encaissements et décaissements des fonds pour nous permettre de nous concentrer sur le coeur du WordCamp.

Je me suis également chargé de la coordination entre l’équipe et cette organisation centrale des WordCamps. Nous l’avons sollicitée à de nombreuses reprises sur des points particuliers comme le contenu des plans de sponsoring, la mise en place de notre dispositif d’accessibilité pour les personnes ayant des difficultés d’audition, et chaque fois que nous avions des doutes par rapport au respect de la charte des WordCamps, des marques « WordCamp » et « WordPress » ou encore de la licence GPL de notre projet open source.

Elle a toujours répondu avec une très grande réactivité, ce qui est super appréciable d’autant plus lorsqu’il s’agit des mises en paiement des factures des fournisseurs

J’ai également partagé avec elle des points réguliers sur l’avancée de nos travaux tout au long de la phase de préparation et à l’issue de notre rencontre communautaire.

Ses outils collaboratifs

Je crois qu’un outil de type Slack ou Stride est quasiment devenu indispensable pour échanger de manière asynchrone ou synchrone et surtout ordonnée. Je crois cependant qu’il est important de veiller à ce que chaque idée partagée soit remerciée et félicitée avant d’éventuellement être discutée et améliorée ou abandonnée et tout particulièrement sur ce type d’outil.

Un répertoire commun pour échanger des fichiers de type Google Drive ou Dropbox est également très utile. L’avantage du premier est que nous pouvons créer des questionnaires très facilement et exploiter les réponses tout aussi simplement.

Pour nos douze réunions audio : à la suite de difficultés avec Google Hangout (nombre de participants limité), nous avons opté pour Skype. Zoom.us est une autre possibilité à laquelle j’ai renoncé car l’offre gratuite ne permet de réaliser des réunions de groupe que durant 40 minutes (je suis trop bavard pour que ça colle!).

Nous avons également mis en place d’autres outils pour cette édition 2018 :

• un groupe flickr pour centraliser toutes les photos du WordCamp de Paris, l’avantage du groupe est qu’il permet aux photographes de garder la paternité sur leurs chefs d’oeuvre.
• un compte GitHub pour la collaboration sur le design du site officiel du WordCamp et les extensions WordPress que nous avons créées et utilisées pour organiser la récolte des propositions de sujets de conférence ou d’activités participatives.
• une chaîne YouTube pour diffuser l’évènement en direct.

La communication « externe »

Même si ce n’était pas un de mes domaines de contribution, en passant Valérie a excellemment oeuvré sur le sujet, je pense qu’il est important de dire quelques mots sur cette partie très importante d’un WordCamp.

Si les media sociaux sont d’incontournables relais, je crois qu’il est hyper important de commencer à démontrer les fabuleuses capacités de WordPress en publiant régulièrement sur le site officiel du WordCamp.

Étant donné notre positionnement communautaire et commémoratif nous avons décidé :

• de poster des interviews de chacun des membres des équipes des organisateurs, des orateurs et des volontaires.
• de compléter les présentations des sponsors « métalliques » (platine, or, argent, bronze) par un article spécifique pour remercier l’ensemble des micro-sponsors.
• de retracer l’histoire des dix années de notre rassemblement communautaire parisien. Cette série d’articles permettant, par ailleurs, de faire découvrir le concept de WordCamp à celles et ceux qui n’y étaient pas encore familiers.

Par ailleurs, chaque organisateur·trice a publié un article pour présenter ses réalisations : ce sont les mieux placé·e·s pour en parler et ils·elles l’ont admirablement fait. En complément nous avons publié des points d’étape à 100 et à 50 jours de l’événement ainsi qu’un bilan final une fois le budget bouclé. Ces informations étaient pour nous l’occasion d’associer plus intimement la communauté avec les progrès de son rassemblement et de partager nos pratiques avec celles et ceux qui souhaitent se lancer dans l’organisation d’un WordCamp prochainement.

Vous avez réagi directement à ces articles en postant 44 commentaires et des discussions sont intervenues sur les media sociaux, j’aurai personnellement adoré que chacun·e concède l’effort supplémentaire de remplir un rab d’un ou trois champs de formulaire pour que l’ensemble des conversations interviennent sur le site du WordCamp.

Enfin, je regrette de ne pas avoir trouvé le temps pour communiquer beaucoup plus auprès des membres de notre groupe meetup. Je l’ai fait à l’occasion de mon intervention sur Gutenberg du 8 février dernier, mais je reconnais que c’est insuffisant. Pour le prochain WordCamp Paris, c’est un des points d’effort personnel que je souhaite améliorer.

Deux extensions WordPress au service d’une sélection des contenus plus participative.

L’application pour le WordCamp Paris 2018 a été validée tout début août par l’organisation centrale des WordCamps. Sitôt confirmée, j’ai étoffé mes contributions au projet « WordCamp Talks » en le forkant sur le GitHub du WordCamp Paris.

Nous l’avons utilisé pour organiser la collecte des propositions de conférence pour le WordCamp. Deux de ses fonctionnalités ont été très intéressantes pour nous faire gagner du temps et rendre la démarche de sélection des conférences plus ouverte :

• la possibilité d’intégrer à l’aide de l’outil d’importation du site WordPress du WordCamp les conférences et orateurs retenus (ce qui nous a permis de publier le programme des conférences et des ateliers dans des délais records ! ),
• la possibilité d’accueillir des évaluateurs externes à l’organisation grâce aux fonctions d’anonymisation des propositions.

J’ai enchaîné avec la création de l’extension « AntiConférences », spécialement prévue pour nous permettre d’organiser l’OpenBar du WordCamp.

Dans ce cas, l’ouverture était totale puisqu’et la proposition de sujets et leur sélection étaient laissées entre les mains des participants du WordCamp Paris 2018. Si certain·e·s d’entre nous avaient une appréhension quant à sa prise d’assaut, nous avons eu la surprise de constater que relativement peu d’entre vous n’avez osé vous exprimer que ce soit pour soumettre des activités ou voter pour celles qui retenaient votre préférence.

Le sprint final !

Pour nous, il a commencé le 8 mars en début d’après-midi. Nous avions rendez-vous pour préparer la répartition des goodies de sponsor dans les totebags.

De mon côté, j’ai terminé l’équipement du vestiaire que nous avions prévu de bricoler en fonçant récupérer des tickets de vestiaire à l’Office Dépôt du coin, étant donné qu’il faisait défaut à la « MAS ». Déjà le matin, j’étais passé au « Casto » de la rue de Flandres pour récupérer une centaine de cintres en urgence vu qu’Amazon Prime s’était grippé suite à l’épisode neigeux qui s’était abattu sur notre région plus tôt.

Une fois ces préparatifs terminés, nous avons rejoint les orateurs, certains sponsors et les bénévoles pour déguster le buffet dînatoire que Sylvie avait brillamment organisé.

Ce fut très agréable (et rassurant !) d’échanger avec les personnalités qui allaient contribuer une nuit plus tard à la réussite du 10e WordCamp de Paris. J’ai personnellement été très ému de retrouver mon ami Boone qui m’avait fait l’énorme plaisir de traverser l’Atlantique pour s’engager dans la contribution au premier WordCamp de Paris que je coordonnais.

C’est le WordCamp !

L’équipe d’organisation se confond alors avec celle des bénévoles. Grâce au travail de Florian, nous avions un planning millimétré des tâches que nous devions accomplir. Il m’avait laissé une position d’électron libre toute la matinée pour pouvoir naviguer dans les différents espaces de la « MAS », contribuer aux différents chantiers d’installation qui le nécessitaient, faire face aux urgences et tenter d’animer la table de contribution au Core de WordPress qui était prévue au programme de notre OpenBar.

Le moment critique était la mise en place du « livestream », c’était la première fois qu’on relevait ce défi. Olivier a réussi ce tour de force avec brio et m’a passé les URL des deux flux que j’ai pu mettre en place juste à temps sur le site du WordCamp.

Cette année, nous avons proposé aux sponsors de réaliser un petit film pour se présenter eux-mêmes à nos participants et souhaiter un joyeux 10e anniversaire au WordCamp Paris, l’histoire de nous mettre dans l’ambiance de notre célébration et de les associer un peu plus à notre rencontre communautaire.

Je pouvais me rendre à la table de contribution au Core de l’OpenBar l’esprit tranquille et plein d’espoirs étant donné que Boone s’était rendu disponible pour nous faire profiter de son expérience de « Core committer ». Malheureusement seul Maxime a répondu présent à cette opportunité et j’ai pu remballer les clés USB contenant les environnements de développement VVV que j’avais préparé avec amour. Dommage..

Quoiqu’il en soit, j’ai dû écourter ma participation à la discussion qui avait remplacé le moment de contribution initialement prévu car des problèmes techniques parasitaient les ateliers de la salle d’en face.

J’étais fou et sur le cul ! Comment était-il possible qu’on rencontre encore des difficultés de projection de l’écran d’une machine de nos jours ? On a essayé toutes les combinaisons de connectique : rien n’y a fait. A partir du moment où le raccordement de la machine nécessitait l’utilisation d’un port USB-C le flux vidéo était en vrac. Résultat : Kirsten qui nous parlait de Webpack a souffert le martyr durant tout son atelier car elle avait impérativement besoin de la configuration de sa machine pour démontrer l’outil. On a bien essayé de compenser en partageant ses slides sur Twitter, mais c’est resté insatisfaisant.

Lorsque Riad a succédé à Kirsten, nous nous dirigions vers la même problématique vu que sa machine aussi nécessitait un raccordement via son port USB-C . Et d’ailleurs, ça s’est très vite vérifié : au moins on ne pouvait pas reprocher au projecteur une certaine inconstance ! Heureusement, j’avais pris avec moi ma machine qui elle, plus ancienne, utilise un port « Thunderbolt » pour le même raccordement. S’il n’a pas été possible d’en faire profiter Kirsten en raison de son environnement de développement spécifique, pour Riad ça a été différent puisque je dispose de l’environnement de développement de Gutenberg, étant donné que je contribue au projet. Du coup, après quelques checkouts pour récupérer les toutes dernières versions de Gutenberg et de l’extension qui lui servait à animer son atelier, il a pu le mener à bien et dans des conditions convenables.

Il était temps de déjeuner pour essayer de compenser ma déception concernant ces difficultés techniques très pénalisantes. A mon arrivée dans la salle « girafe » qui nous servait pour la restauration, je constate ce que beaucoup de participants nous ont rapporté lors de l’enquête de satisfaction : un raz de marée avait submergé le buffet déjeunatoire qu’avec Marc nous avions prévu pour 300 personnes alors que nous étions légèrement moins « Et bien ça creuse les conférences au sujet de WordPress ! ». Manifestement, nous avons manqué de vigilance sur ce point précis. Nous retenons la leçon pour le prochain WordCamp, cette formule est trop risquée par rapport à celle des portions individuelles. Par ailleurs Marc m’a fait part de l’aide qu’il a reçu de la part de certaines participantes pour « éponger » les dégâts du tsunami : aussi je tenais à remercier Mathilde, Béryl et Emmanuelle .

Alors, à défaut d’un bol de soupe, j’ai pris un bon bol d’air pour décompresser. En effet le plus important pour moi, ce n’était pas l’estomac c’était de fiabiliser le dispositif de projection des ateliers. De retour à l’intérieur, Claire m’a alors donné l’opportunité d’échanger avec Sophie et Emmanuelle, ça a été génial d’avoir le retour des premières bénéficiaires du dispositif de sous-titrage en temps réels que nous avons introduit lors de cette édition anniversaire du WordCamp de Paris.

Il est temps de regagner la salle des ateliers… Un peu avant 14h, arrive Maxime.. Sa machine, elle aussi, utilise le problématique port USB-C et là c’est de nouveau la cata car tout comme Kirsten : son environnement de développement pour Gulp est spécifique. Heureusement, Marie de l’équipe des bénévoles a eu l’éclair de génie qui nous a sauvé : utiliser« AirPlay » pour recopier l’écran de la machine de Maxime sur celui de la mienne qui à ce moment de la partie est toujours la plus fiable pour se faire comprendre du projecteur. Le dispositif de secours pour la suite des ateliers était tout trouvé ! Bravo Marie

L’après-midi, j’étais le gardien du temps de la salle des conférences. Et ça tombait super bien car ça me permettait de vivre un moment privilégié : la performance de Boone au WordCamp de Paris. Il a été exemplaire et nous a donné une leçon de courage managérial en intervenant en français sur un sujet très personnel et très éclairant sur la manière dont est organisée la contribution au code de WordPress. Si vous n’avez pas vécu ce moment extraordinaire, je vous recommande vivement de méditer son propos.

Sa conclusion que je vais paraphraser est magnifique : les technologies, les détails techniques d’un projet de logiciel libre sont en perpétuelle évolution donc éphémères. La seule constante vitale à la survie d’un tel projet est sa communauté. Voilà pourquoi, le chef de projet doit se concentrer sur la dynamique communautaire plutôt que sur les détails techniques du projet.

La suite des conférences était également très intéressante : Tony nous a parlé de la faculté de WordPress à accompagner les start-ups dans la réalisation de leur site applicatif, Claire nous a éclairé sur l’accessibilité dans WordPress, Daniel nous a mis en garde par rapport aux impacts à court et long terme de nos choix (extensions, thème, réglages, …) dans notre WordPress et CreaNico nous a livré les 10 leviers de l’optimisation du SEO des sites WordPress.

Je me suis alors éclipsé pour contribuer à la mise en place des derniers détails de la surprise que nous avions prévu pour clôturer le WordCamp : souffler les bougies de notre gâteau d’anniversaire en compagnie de tous les « lead orgas » des précédentes éditions de notre rassemblement.

Avant de poursuivre la fête dans l’ambiance très « high tech » que nous avait mijoté Florent et Laurent en garnissant notamment le DAD, lieu de l’after party, de stands de jeux de réalité virtuelle, il nous restait à partager avec nos participants la traditionnelle photo de groupe et nos remarques de clôture.

S’agissant de ces dernières, je regrette que nous n’ayons pas eu le temps de faire monter sur scène les orateur·rices, les bénévoles et les organisateur·rices qui ont tou·te·s rempli leur rôle à merveille

En conclusion, l’expérience que j’ai vécue est très enrichissante : moi qui suis beaucoup plus à l’aise lorsqu’il s’agit de faire, j’ai beaucoup appris de mon rôle de facilitateur (pour reprendre le terme de la conférence de Boone) et de coordinateur de l’équipe.

Je suis hyper satisfait et fier de la manière dont nous avons collaboré au sein de l’équipe : chacun·e était motorisé·e par une furieuse envie de mener à bien notre projet de WordCamp Paris pour 2018 tout en faisant preuve de bienveillance, de solidarité et d’un esprit d’entraide remarquable. Nous l’avons mené à son terme ce WordCamp, sans casse pour nos populations et avec enthousiasme. Nos erreurs sur certains détails nous permettront de faire encore mieux la prochaine fois. Bravo et Merci à nous douze, comme je disais souvent dans notre Slack : « super taf » !

Vive WordPress, vive le WordCamp Paris.

Au delà d’être une source alternative, indépendante, ouverte, libre et gratuite d’extensions WordPress, l’Entrepôt regroupe et mutualise aussi un ensemble de fonctions pour simplifier la vie de leurs créateurs et de leurs utilisateurs.

Par exemple et pour rappel :

• une API de routines de montée de version permet aux créateurs de gagner en sérénité pour ces opérations qui peuvent énormément solliciter la base de données.
• Une interface de gestion des versions des extensions installées permet aux utilisateurs d’en avoir une meilleure maîtrise.

Renforcement du pouvoir “nettoyant” du centre de notifications.

Le centre de notifications de l’Entrepôt a été introduit à l’occasion de sa version 1.1.0. Son objectif principal est de dérouter les notifications intrusives/abusives de certains thèmes ou extensions. Pour se rafraîchir la mémoire, voici un avant/après l’activation de l’Entrepôt.

Avant

J’exagère à peine par rapport au caractère intrusif de certaines notifications sur vos écrans d’administration : il est parfois nécessaire de « scroller » pour commencer à voir le contenu de la page affichée.

Après

Grâce au centre de notifications de l’Entrepôt, vos écrans d’administration sont enfin exploitables plus rapidement !

Quoi de neuf dans la version 1.3.0 ?

Le centre de notifications affiche désormais une version épurée de mise en forme et tronquée à 20 mots des notifications. Pour pouvoir consulter la notification d’origine, un nouveau bouton bleu en forme de loupe permet de l’afficher dans des conditions « régulières ». Le bouton en forme de poubelle permet toujours de repousser la ou les notification(s) pour qu’elle(s) ne s’affiche(nt) plus pour votre navigateur courant. La démonstration ci-dessous vous permet de visualiser le fonctionnement du centre.

Télécharger ou Mettre à jour l’Entrepôt.

Si vous avez activé une précédente version de l’Entrepôt dans votre WordPress, comme toute autre extension hébergée sur le répertoire officiel de WordPress.org, vous pourrez directement procéder à sa montée de version depuis l’administration de votre site. Si vous n’avez pas encore activé l’Entrepôt, vous pouvez télécharger son archive ZIP ci-dessous. Une fois téléchargée, vous pourrez utiliser le téléversement manuel de votre administration des extensions pour l’installer puis l’activer.

Entrepôt

Requiert la version 4.8 de WordPress

Afficher la page GitHub de la version

Télécharger la version 1.3.0

Il y a de cela quelques jours l’un d’entre vous m’a contacté pour me demander si je connaissais des astuces pour lui permettre d’intégrer des fonctionnalités de mise en forme basique des activités enregistrées dans son site communautaire équipé de BuddyPress. Il indique par ailleurs que l’activation de l’extension TinyMCE Advanced ne lui a pas permis d’atteindre son objectif. Alors, malheureusement, je ne connais pas de truc miracle qui exaucerait son souhait avec un minimum d’efforts, désolé. Si vous en connaissez un de votre côté : n’hésitez pas à le partager en commentaires ! Pour atteindre le résultat attendu, il va falloir se retrousser les manches et travailler

J’aurai pu en rester là et laisser voguer cette bouteille dans l’océan pour réserver mon investissement personnel pour cette réponse à ma famille car comme dit souvent ma douce et tendre avec des gros yeux : « mais pourquoi tu te prends la tête pour ces inconnus : t’es jamais payé en retour ! ». Et oui pourquoi ! Surtout que ma page de donation doit être la moins visitée de tout l’internet Bref, tout ça pour faire comprendre à ceux qui me reprochent parfois d’avoir quitté le répertoire officiel des extensions de WordPress.org que j’aurais peut-être pu continuer à encaisser la rudesse et la rage de certains sujets de support ou de revue d’extensions si d’autres avaient visité cette page pour y larguer quelques « pourboires ».

Ceci étant dit, revenons à notre problématique initiale.

Modifier le formulaire d’ajout d’activités de BuddyPress.

L’extension spécialisée dans la mise en place de communautés pour WordPress intègre (entre autres !) un composant permettant aux utilisateurs de poster des annonces publiques et de journaliser leurs interactions avec des messages standards auto-générés (ex: Mathieu a changé sa photo de profil) : il s’appelle « Activités ».

La rédaction de ces annonces, à la différence des articles et des pages WordPress s’effectue sur le frontal de votre site se rapprochant ainsi beaucoup plus des commentaires qui peuvent garnir parfois vos articles. La particularité de ces conversations est que leurs auteurs doivent impérativement être membres du site et authentifiés pour être publiées et que leur modération ne peut s’effectuer qu’à posteriori.

Dans sa version la plus basique, cette publication requiert la soumission d’un formulaire constitué d’un champ de texte multi-ligne et d’un bouton d’enregistrement que vous atteindrez en visitant la page des activités BuddyPress de votre site.

Une bonne partie de la solution que certains d’entre vous entrevoient déjà est de transformer ce champ multi-ligne en lui appliquant la fonction wp_editor(). Pour plus de détail à son sujet, c’est par là.

Certes, mais à moins d’être un gros bourrin qui modifie le code source de BuddyPress et qui s’étonne par la suite de perdre son éditeur riche à chacune des mises à jour de l’extension communautaire : il vous faudra prendre quelques minutes pour comprendre la hiérarchie des gabarits de BuddyPress afin d’obtenir un résultat plus durable.

Mise en place du thème pour profiter de cette hiérarchie

Il s’agit donc, d’abord, d’adapter votre thème si vous l’avez écrit ou de créer un thème enfant du thème que vous avez téléchargé ou acheté et de l’activer.

Dans mon « étude de cas » : j’ai choisi de créer un thème enfant de TwentySeventeen. Pour remplacer le champ multi-ligne en question, j’ai reproduit la hiérarchie des gabarits de BuddyPress en me concentrant sur le gabarit utilisé pour afficher le formulaire de création d’activités buddypress/activity/post-form.php. Pour le contenu du gabarit post-form.php de mon thème, j’ai copié le contenu du même fichier du pack de gabarits « Héritage » de Buddypress. Ce pack existe depuis la version 1.7 de l’extension et il accompagne l’API de compatibilité avec les thèmes WordPress conçu par BuddyPress pour injecter les contenus propres à ses fonctions communautaires.

L’API de compatibilité avec les thèmes WordPress de BuddyPress agit en deux temps : 

• elle utilise un mécanisme de filtre du contenu des pages WordPress référencées comme racines de ses composants communautaires pour injecter ses portions de gabarit au moment du rendu de ces pages de votre site.
• juste avant ce rendu, elle vérifie si une portion de gabarit du même nom qui serait positionné selon une arborescence identique au pack de gabarits actif (dans notre exemple « Héritage ») existe dans le thème WordPress actif. Si c’est le cas, elle utilise le gabarit du thème WordPress, autrement elle utilise celle du pack de gabarits actif. La capture d’écran ci-dessus illustre ce mécanisme puisque c’est bien le gabarit de mon thème enfant qui a été rendu dans la page des activités au lieu de celui du pack de gabarits actif de BuddyPress.

Pour votre information la version 3.0 de BuddyPress est en cours de finalisation. Sa sortie prochaine célèbrera les 10 ans d’existence de l’extension et introduira notamment un deuxième pack de gabarits, plus modernes, s’intitulant « Nouveau ». Une fois cette version publiée (courant mai 2018), vous aurez alors le choix depuis les réglages des options BuddyPress de l’administration de votre WordPress d’activer l’un de ces deux gabarits en fonction de vos préférences.

A titre de comparaison, voici le même formulaire généré par le pack de gabarits « Nouveau ».

Surcharger le JavaScript de BuddyPress.. ou pas !

Si vous observez bien le premier formulaire : celui généré par « Héritage », vous constaterez que vous ne pourrez pas publier votre activité car le bouton de publication n’est plus accessible une fois que nous avons transformé le champ multi-ligne par une instance du WP Editor. Coincé, ahaha !

« Héritage » utilise en effet un fichier JavaScript monobloc se basant sur la librairie jQuery pour dynamiser ses interfaces. Ce fichier est chargé sur toutes les pages BuddyPress et contient toutes les interactions des différents composants disponibles dans l’extension. Par ailleurs, ces fonctions sont très sensibles au respect du balisage HTML et de l’intitulé des attributs d’identifiant et de classe des différentes balises du pack de gabarits. L’avantage de cette « faiblesse » est que vous pouvez l’exploiter pour proposer une version plus « old school » de l’expérience de publication des activités en changeant par exemple les attributs d’identifiant de certaines balises. Ce faisant, vous déroutez ce JavaScript gargantuesque et ses fonctions de publication sans rechargement de la page grâce à son approche Ajax pour retomber sur un procédé classique de soumission de formulaire avec rechargement de page.

CQFD : en modifiant l’attribut d’identifiant de deux balises (#whats-new-options et #aw-whats-new-submit), le bouton « Publier la note » apparaît et sur son clic : la page est rechargée et l’activité publiée.

Si, à présent, vous vous intéressez au deuxième formulaire : celui généré par « Nouveau », on s’aperçoit que cette étape de modification des attributs de balise n’est pas nécessaire. Vous pourrez en effet directement profiter d’un traitement avec rechargement de la page de vos activités dans le cadre de ce pack de gabarits.

Maintenant, si vous souhaitez garder le comportement dynamique liée à l’approche Ajax, il sera nécessaire de prévoir la création d’un JavaScript pour imiter les codes d’ajout d’activités que chacun des deux packs de gabarits utilisent. Pour plus d’informations sur ce sujet, je vous invite à parcourir le JavaScript du thème enfant que j’ai préparé pour accompagner cet article.

Personnaliser notre WP Editor pour plus de cohérence avec le contexte des activités BuddyPress.

Je crois qu’il est absolument nécessaire d’effectuer cette personnalisation dans la mesure où le balisage autorisé pour le contenu des activités est beaucoup plus restrictif qu’il ne l’est pour les articles ou les pages de WordPress. Pour connaître les balises autorisées pour le contenu de nos activités, il suffit de s’intéresser à la fonction bp_activity_filter_kses() de BuddyPress (ce lien vous permet de la consulter).

Adaptation de la barre des commandes du WP_Editor.

On s’aperçoit qu’il est donc superflu de garder un certain nombre de commandes de notre WP_Editor :

• la liste déroulante pour mettre en forme des titres,
• le bouton pour ajouter des citations,
• les boutons d’alignement de texte,
• le bouton pour ajouter le marqueur « Continuer la lecture »,
• et les boutons pour afficher en plein écran ou encore la barre des commandes avancées.

En revanche, il peut être intéressant de permettre aux utilisateurs de votre site n’ayant pas la capacité de téléverser des fichiers de pouvoir intégrer des images distantes à leur contenu.

Pour parvenir à cette adaptation, il suffit d’utiliser l’API des plugins de WordPress et en particulier sa fonctionnalité de filtre. La cible de notre filtre est mce_buttons et une bonne technique pour éviter d’impacter les autres instances du WP_Editor (notamment celle de l’éditeur classique de vos articles et pages) consiste à précéder l’utilisation de la fonction par l’insertion d’un filtre et d’y succéder le retrait de ce filtre. Je vous invite à observer les lignes 27 et 42 du morceau de code ci-après.

La fonction imath_wp_editor_buttons() est celle qui sera appelée par le filtre en question et grâce à elle nous pouvons désactiver les commandes superflues de notre WP_Editor et lui ajouter la commande d’insertion d’images distantes.

Intégrer le support des mentions BuddyPress

BuddyPress apporte de nombreuses fonctions communautaires pour permettre à vos utilisateurs d’interagir entre eux. L’une d’entre elles consiste à associer un autre utilisateur à votre activité en le mentionnant. Pour cela, vous pouvez vous rendre sur sa page de profil et cliquer sur le bouton « Message public » comme illustré ci-dessous.

Il est également possible, directement depuis le champ multi-ligne de création d’activités de déclencher l’affichage d’une liste d’utilisateurs en initialisant la saisie du caractère @ suivi des premières lettres du nom de l’utilisateur recherché.

Etant donné que nous avons transformé ce champ multi-ligne, il est important de maintenir ces deux fonctionnalités pour les utilisateurs.

Pour la première (le clic sur le bouton d’action du profil de l’utilisateur à mentionner), c’est assez simple puisqu’il s’agit de pré-remplir le contenu de notre WP_Editor en fonction du paramètre $_GET['r'] envoyé dans l’URL. Il contient le nom d’utilisateur de la personne à mentionner, reportez-vous à mon adaptation (ci-dessous) des lignes 6 à 8 de la fonction vue plus haut  imath_activity_editor() .

Pour la seconde, c’est plus complexe car BuddyPress réserve l’intégration de la liste dynamique de choix des utilisateurs à mentionner aux écrans d’édition des articles et des pages WordPress. Il sera donc nécessaire de prévoir un code JavaScript qui assure cette intégration en s’assurant que l’éditeur a bien été complètement initialisé. Le JavaScript du thème enfant qui accompagne cet article intègre cette fonctionnalité, voici les lignes concernées.

Personnaliser l’éditeur de Media pour les utilisateurs ayant la capacité de téléversement de fichiers.

Vous pouvez vous affranchir de cette étape si vous décidez de désactiver l’éditeur de Media qui accompagne le WP_Editor par défaut. Pour cela, il suffit d’éditer le paramètre media_buttons du tableau passé en troisième argument de la fonction wp_editor(). En le fixant à false tout le monde disposera du bouton d’insertion d’images distantes !

S’il vous reste du courage pour aller au bout de cet article, voici ce qu’il me semble important de considérer pour éviter des surprises avec vos utilisateurs ayant des rôles qui intègrent la possibilité de téléverser des fichiers (Administrateur, Editeur et Auteur. Voir plus si vous personnalisez les rôles de WordPress !).

Tout d’abord, comme nous l’avons vu plus haut, le balisage autorisé pour le contenu des activités est plus restrictif que celui des articles et des pages. Et s’agissant des Media : seule la balise img est prise en charge. Il est donc superflu de maintenir le menu latéral de l’éditeur des media qui permet d’insérer des galleries de photos, ou des playlists de vidéos et d’audios. Pour le masquer, il suffit d’ajouter une nouvelle classe intitulée « hide-menu » à l’attribut correspondant de la balise .media-frame . Vous pouvez consulter ces lignes de code pour avoir une meilleure idée sur la manière de réaliser cette opération (en JavaScript) en étant certain que l’éditeur de Media a été initialisé.

Ensuite, il est également important de s’assurer que :

1. seules des images pourront être téléversées,
2. seules des images seront retournées par la bibliothèque de Media du deuxième onglet de l’interface.

Pour y parvenir, il est nécessaire d’ajouter 3 nouveaux filtres. Deux d’entre eux utiliseront la même approche que pour la personnalisation des boutons de la barre de commandes du WP_Editor vu plus haut (ajout avant la fonction wp_editor() et retrait juste après), ils concerneront :

• la personnalisation des types de fichier supportés par la librairie de téléversement utilisée par l’éditeur de Media (Plupload.js) : c’est l’objet de la fonction bp_activity_2017_upload_mimes() du thème enfant qui accompagne cet article.
• la personnalisation des choix disponibles dans la liste déroulante de filtrage par type de l’éditeur de Media : ce même thème utilise pour cela sa fonction bp_activity_2017_mime_types().

Nous retrouvons bien, dans ce thème, l’ajout et le retrait de ces deux filtres portant respectivement sur upload_mimes et post_mime_types autour de la fonction wp_editor() afin qu’ils produisent leurs effets.

Le troisième filtre est à positionner d’une manière plus globale sur le marqueur permettant de personnaliser les arguments de la requête Ajax qui peuple les éléments de la bibliothèque : pour le thème enfant accompagnant l’article, il s’agit de bp_activity_2017_query_attachments_args, comme illustré par ces lignes de code. Etant donné que nous sommes sur un scope plus global, il est primordial de limiter l’action de ce filtre au contexte du composant des activités de BuddyPress, raison pour laquelle la condition bp_is_activity_component() doit être satisfaite pour autoriser la restriction aux images pour la bibliothèque de Media.

Pour faire une respiration, bien méritée, je vous propose la vidéo de démonstration ci-après qui illustre ce qui a été accompli jusqu’à présent.

Enfin, parce que les détails sont importants, il reste un dernier filtre à positionner : celui qui va modifier l’intitulé du bouton principal d’insertion de l’image. En effet, au lieu de « Insérer dans la page » il est plus adapté d’indiquer « Insérer dans l’activité ».

Télécharger le thème enfant

Le bouton ci-dessus vous enverra sur le dépôt GitHub d’un thème prêt à l’emploi qui reprend chacune des étapes décrites dans cet article. Il intègre également des informations passées sous silence comme une feuille de style pour améliorer la présentation du formulaire dans les gabarits des packs « Héritage » et « Nouveau ». Ce thème n’envisage pas tous les cas de figure : j’estime vous avoir montré suffisamment de chemin pour vous permettre de réaliser les ajustements que votre configuration BuddyPress nécessitera. En particulier, le composant des Groupes à partir desquels il est possible de publier des activités n’est pas supporté et le thème vous le fera savoir si vous avez activé ce composant !

Enfin, par rapport au message qui m’a été envoyé via ma page de contact et qui est à l’origine de cet article. Je précise que je ne suis pas un génie sorti d’une lampe qui exhausse des voeux. Je ne crois pas d’ailleurs qu’il existe de telles créatures. Il n’y a que très rarement des « trucs » lorsqu’on souhaite faire les choses consciencieusement : personnaliser à ce niveau BuddyPress (ou WordPress d’ailleurs) nécessite du travail, des recherches, de la formation et donc du temps qu’on n’utilise pas sur autre chose.

Je n’attends rien en retour à titre personnel, cela fait bien longtemps que je me suis fait une raison sur le comportement individualiste des « useurs » de WordPress. Mon espoir est que le lecteur investira en retour de son temps pour le projet open source BuddyPress en participant notamment à sa période de bêta-tests : la version 3.0 de BuddyPress introduira un nouveau pack de gabarits très modernes et il est important d’y contribuer dans cette dernière ligne droite.

La prochaine version majeure de WordPress, la 5.0.0, est dépendante des progrès accomplis concernant l’intégration du projet Gutenberg (contenant notamment l’éditeur moderne). En attendant, les versions mineures à venir peuvent être amenées à intégrer de nouvelles fonctionnalités et ne sont plus seulement des versions de maintenance ou de sécurité. Voici une situation problématique, qui je l’espère perdurera le moins longtemps possible.

Aussi, à la différence des 5 versions mineures qui l’ont précédée, la 4.9.6 introduira des évolutions et des adaptations liées à la mise en conformité de WordPress par rapport à la prochaine entrée en vigueur du règlement général de protection des données (RGPD).

Ok, mais en quoi c’est risqué ?

Tout simplement parce qu’une version mineure bénéficie de la fonctionnalité de mise à jour automatique, et sauf erreur de ma part : ce sera bien le cas pour cette version 4.9.6. Or, si une regression se glisse dans les travaux de l’équipe de développement, vous ne pourrez pas l’éviter et ce risque augmente lorsqu’on travaille sur des évolutions.

Alors, comme le planning de la 4.9.6 prévoit la publication de la première version bêta pour aujourd’hui, le 1er mai 2018 …

Je vous recommande vivement de participer à cette période de bêta-tests et de rapporter tous les comportements inadaptés que vous constateriez sur l’environnement de suivi des versions et des rapports d’anomalie de WordPress.

Pour récupérer cette 4.9.6 bêta 1, je vous invite à surveiller l’annonce qui devrait être faite prochainement sur l’étiquette 4-9-6 du site d’information des contributeurs du Core : make.wordpress.org/core.

Une regression dans l’expérience utilisateur

Si les contributeurs de cette version font un excellent travail sur le thème de la conformité au RGPD (ou GDPR en anglais) – énorme merci à eux – j’ai d’ores et déjà constaté que les adaptations apportées au formulaire de publication des commentaires ont un impact négatif sur l’information des utilisateurs une fois le commentaire envoyé pour modération.

C’est selon moi d’autant plus fâcheux, que ça introduit un déséquilibre quant au niveau d’information fourni à ceux qui autorisent l’utilisation des cookies pour la sauvegarde temporaire de leurs informations personnelles par rapport à celui de ceux qui la refusent.

J’ai évidemment fait part de mon inquiétude avec insistance sur l’environnement dont je parlais plus tôt. Malheureusement, la résolution de cette inquiétude est remise à « si on a le temps ou sinon lors de la prochaine version« .

Impacts possibles de la regression

Dans l’état actuel de la considération du rapport d’anomalie que j’ai remonté, la regression est inévitable pour les administrateurs de site car, je le rappelle, la 4.9.6 est une version mineure qui se met automatiquement à jour. Ce qui est certain, c’est que le visiteur soucieux de ne pas utiliser de cookies sera dans la confusion la plus totale !

Mon commentaire a-t-il été sauvegardé ? Pas certain, allez j’en renvoie un autre l’histoire d’être sûr.. Même résultat, bon j’utilise le formulaire de contact pour avertir l’administrateur de ce site… 

Le visiteur…

Un utilisateur sceptique, ça va. Mais si tous ceux qui commentent le font plusieurs fois, ce qui est probable étant donné que la case à cocher est par défaut inactivée, ça peut vite polluer ! Je n’imagine même pas les cas, sans doute moins nombreux, où l’administrateur utilise un formulaire de commentaire personnalisé au lieu de la fonction comment_form().

Enfin, les développeurs d’extensions liées aux commentaires noteront que la fonction wp_get_current_commenter() qui habituellement renvoie les informations du commentateur non authentifié, pourra renvoyer un tableau de valeurs vides.

Maintenir la même expérience pour tous les commentateurs !

J’espère que le temps restant avant la publication de cette 4.9.6 permettra à l’équipe Core de WordPress de revenir sur cette anomalie. En attendant, comme je vous adore mes chers commentateurs, pas d’inquiétude ! Je ne prends pas de risque grâce à l’extension que j’ai conçue à partir de la rustine partagée sur le rapport d’anomalie 

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.

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

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

Afficher la page GitHub de la version

Télécharger la version 1.1.0

Le 8 février dernier, WP Paris organisait un Meetup dédié à Gutenberg et j’ai eu l’honneur de faire (re)découvrir à la soixante-dixaine de courageux qui avaient bravé des conditions météorologiques défavorables l’éditeur moderne.

Qui a entendu parler de Gutenberg ?

Qui est inquiet à son sujet ?

C’est avec ces deux questions que j’ai commencé mon propos. Elles ont, d’ailleurs, reçu à peu près le même nombre de mains levées. Deux raisons semblent expliquer la réserve vis à vis de la première phase du projet Gutenberg.

D’abord comme le titre le premier « slide » de mon diaporama, l’arrivée de l’éditeur moderne dans le « Core » de WordPress met fin à plus de 10 ans de stabilité de notre expérience de publication d’articles, de pages et de tout autre type de contenu.

Ensuite, pour certains des participants, l’éditeur moderne : c’est aussi la remise en cause des dispositifs qu’ils avaient mis en place à l’aide d’extensions pour simplifier, sécuriser et améliorer la prise en main par leurs clients des développements ou intégrations entrepris pour leurs comptes.

« Ça va bien se passer ! »

Rassurer, c’est l’objectif principal que je m’étais fixé lors de la préparation de mon intervention. J’ai alors pensé que la meilleure manière de transmettre ma confiance dans l’éditeur moderne était de l’utiliser comme support pour sa présentation. L’écran d’édition de mon type de contenu spécifique s’est donc transformé en visionneuse de « slides », le temps du meetup.

Pour me simplifier le passage d’un « slide » à l’autre, j’ai simplement créé un nouveau bloc Gutenberg dont le rôle est d’insérer une pagination vers le lien d’édition de mon précédent et/ou suivant type de contenu. Les caractéristiques du type de contenu hiérarchique ont fait le reste (notamment la possibilité de définir l’ordre ou des rattachements parent).

En plus comme j’avais prévu de démontrer l’éditeur moderne, ce choix s’est révélé très pratique, le moment venu .

Si vous aussi, vous souhaitez profiter de ce bloc pour vos présentations, vous pouvez le récupérer depuis son répertoire sur GitHub.com (les français pourront même importer mes slides).

GutenPrez

Afficher la page GitHub de la version

Télécharger la version 1.0.1

Standardisation, modernité et maîtrise.

J’ai beaucoup insisté sur ces trois points lors de mon intervention.

Premièrement, le choix du projet Gutenberg concernant la persistance des blocs de contenu apportera selon moi une standardisation qui sera très bénéfique aux prochaines fonctionnalités dérivées.

Deuxièmement, baser l’interface de l’éditeur du projet Gutenberg sur un JavaScript moderne et exposer une API qui ne requiert pas de connaissances spécifiques dans la librairie choisie (React) améliore non seulement l’expérience des utilisateurs mais aussi celle des créateurs d’extensions.

Troisièmement, la possibilité d’attacher une combinaison de blocs aux types de contenu grâce à la propriété template de l’objet WP_Post_Type permet d’orienter la rédaction de l’utilisateur d’une manière beaucoup plus intuitive et performante que le recours aux metaboxes et meta données de contenu. Nous disposons même d’un contrôle affiné quant à l’insertion de blocs ou à leur réorganisation grâce à la propriété template_lock du même objet.

Le récapitulatif

Lors de notre meetup, nous avons échangé sur pas mal d’autres points comme la possibilité de garder l’éditeur classique une fois la version 5.0 de WordPress publiée, la réutilisation des blocs ou encore les fonctionnalités contrôlables depuis le thème grâce à la fonction add_theme_support. Si vous souhaitez approfondir le sujet, je vous invite à parcourir une version améliorée des notes que j’avais préparées pour ce meetup.

Au delà d’être une source alternative, indépendante, ouverte, libre et gratuite d’extensions WordPress, l’Entrepôt regroupe et mutualise aussi un ensemble de fonctions pour simplifier la vie de leurs créateurs et de leurs utilisateurs.

Par exemple et pour rappel :

• une API de routines de montée de version permet aux créateurs de gagner en sérénité pour ces opérations qui peuvent énormément solliciter la base de données.
• Une interface de gestion des versions des extensions installées permet aux utilisateurs d’en avoir une meilleure maîtrise.

Renforcement du pouvoir “nettoyant” du centre de notifications.

Le centre de notifications de l’Entrepôt a été introduit à l’occasion de sa version 1.1.0. Son objectif principal est de dérouter les notifications intrusives/abusives de certains thèmes ou extensions. Pour se rafraîchir la mémoire, voici un avant/après l’activation de l’Entrepôt.

Avant

J’exagère à peine par rapport au caractère intrusif de certaines notifications sur vos écrans d’administration : il est parfois nécessaire de « scroller » pour commencer à voir le contenu de la page affichée.

Après

Grâce au centre de notifications de l’Entrepôt, vos écrans d’administration sont enfin exploitables plus rapidement !

Quoi de neuf dans la version 1.3.0 ?

Le centre de notifications affiche désormais une version épurée de mise en forme et tronquée à 20 mots des notifications. Pour pouvoir consulter la notification d’origine, un nouveau bouton bleu en forme de loupe permet de l’afficher dans des conditions « régulières ». Le bouton en forme de poubelle permet toujours de repousser la ou les notification(s) pour qu’elle(s) ne s’affiche(nt) plus pour votre navigateur courant. La démonstration ci-dessous vous permet de visualiser le fonctionnement du centre.

Télécharger ou Mettre à jour l’Entrepôt.

Si vous avez activé une précédente version de l’Entrepôt dans votre WordPress, comme toute autre extension hébergée sur le répertoire officiel de WordPress.org, vous pourrez directement procéder à sa montée de version depuis l’administration de votre site. Si vous n’avez pas encore activé l’Entrepôt, vous pouvez télécharger son archive ZIP ci-dessous. Une fois téléchargée, vous pourrez utiliser le téléversement manuel de votre administration des extensions pour l’installer puis l’activer.

Entrepôt

Requiert la version 4.8 de WordPress

Afficher la page GitHub de la version

Télécharger la version 1.3.0

Il y a de cela quelques jours l’un d’entre vous m’a contacté pour me demander si je connaissais des astuces pour lui permettre d’intégrer des fonctionnalités de mise en forme basique des activités enregistrées dans son site communautaire équipé de BuddyPress. Il indique par ailleurs que l’activation de l’extension TinyMCE Advanced ne lui a pas permis d’atteindre son objectif. Alors, malheureusement, je ne connais pas de truc miracle qui exaucerait son souhait avec un minimum d’efforts, désolé. Si vous en connaissez un de votre côté : n’hésitez pas à le partager en commentaires ! Pour atteindre le résultat attendu, il va falloir se retrousser les manches et travailler

J’aurai pu en rester là et laisser voguer cette bouteille dans l’océan pour réserver mon investissement personnel pour cette réponse à ma famille car comme dit souvent ma douce et tendre avec des gros yeux : « mais pourquoi tu te prends la tête pour ces inconnus : t’es jamais payé en retour ! ». Et oui pourquoi ! Surtout que ma page de donation doit être la moins visitée de tout l’internet Bref, tout ça pour faire comprendre à ceux qui me reprochent parfois d’avoir quitté le répertoire officiel des extensions de WordPress.org que j’aurais peut-être pu continuer à encaisser la rudesse et la rage de certains sujets de support ou de revue d’extensions si d’autres avaient visité cette page pour y larguer quelques « pourboires ».

Ceci étant dit, revenons à notre problématique initiale.

Modifier le formulaire d’ajout d’activités de BuddyPress.

L’extension spécialisée dans la mise en place de communautés pour WordPress intègre (entre autres !) un composant permettant aux utilisateurs de poster des annonces publiques et de journaliser leurs interactions avec des messages standards auto-générés (ex: Mathieu a changé sa photo de profil) : il s’appelle « Activités ».

La rédaction de ces annonces, à la différence des articles et des pages WordPress s’effectue sur le frontal de votre site se rapprochant ainsi beaucoup plus des commentaires qui peuvent garnir parfois vos articles. La particularité de ces conversations est que leurs auteurs doivent impérativement être membres du site et authentifiés pour être publiées et que leur modération ne peut s’effectuer qu’à posteriori.

Dans sa version la plus basique, cette publication requiert la soumission d’un formulaire constitué d’un champ de texte multi-ligne et d’un bouton d’enregistrement que vous atteindrez en visitant la page des activités BuddyPress de votre site.

Une bonne partie de la solution que certains d’entre vous entrevoient déjà est de transformer ce champ multi-ligne en lui appliquant la fonction wp_editor(). Pour plus de détail à son sujet, c’est par là.

Certes, mais à moins d’être un gros bourrin qui modifie le code source de BuddyPress et qui s’étonne par la suite de perdre son éditeur riche à chacune des mises à jour de l’extension communautaire : il vous faudra prendre quelques minutes pour comprendre la hiérarchie des gabarits de BuddyPress afin d’obtenir un résultat plus durable.

Mise en place du thème pour profiter de cette hiérarchie

Il s’agit donc, d’abord, d’adapter votre thème si vous l’avez écrit ou de créer un thème enfant du thème que vous avez téléchargé ou acheté et de l’activer.

Dans mon « étude de cas » : j’ai choisi de créer un thème enfant de TwentySeventeen. Pour remplacer le champ multi-ligne en question, j’ai reproduit la hiérarchie des gabarits de BuddyPress en me concentrant sur le gabarit utilisé pour afficher le formulaire de création d’activités buddypress/activity/post-form.php. Pour le contenu du gabarit post-form.php de mon thème, j’ai copié le contenu du même fichier du pack de gabarits « Héritage » de Buddypress. Ce pack existe depuis la version 1.7 de l’extension et il accompagne l’API de compatibilité avec les thèmes WordPress conçu par BuddyPress pour injecter les contenus propres à ses fonctions communautaires.

L’API de compatibilité avec les thèmes WordPress de BuddyPress agit en deux temps : 

• elle utilise un mécanisme de filtre du contenu des pages WordPress référencées comme racines de ses composants communautaires pour injecter ses portions de gabarit au moment du rendu de ces pages de votre site.
• juste avant ce rendu, elle vérifie si une portion de gabarit du même nom qui serait positionné selon une arborescence identique au pack de gabarits actif (dans notre exemple « Héritage ») existe dans le thème WordPress actif. Si c’est le cas, elle utilise le gabarit du thème WordPress, autrement elle utilise celle du pack de gabarits actif. La capture d’écran ci-dessus illustre ce mécanisme puisque c’est bien le gabarit de mon thème enfant qui a été rendu dans la page des activités au lieu de celui du pack de gabarits actif de BuddyPress.

Pour votre information la version 3.0 de BuddyPress est en cours de finalisation. Sa sortie prochaine célèbrera les 10 ans d’existence de l’extension et introduira notamment un deuxième pack de gabarits, plus modernes, s’intitulant « Nouveau ». Une fois cette version publiée (courant mai 2018), vous aurez alors le choix depuis les réglages des options BuddyPress de l’administration de votre WordPress d’activer l’un de ces deux gabarits en fonction de vos préférences.

A titre de comparaison, voici le même formulaire généré par le pack de gabarits « Nouveau ».

Surcharger le JavaScript de BuddyPress.. ou pas !

Si vous observez bien le premier formulaire : celui généré par « Héritage », vous constaterez que vous ne pourrez pas publier votre activité car le bouton de publication n’est plus accessible une fois que nous avons transformé le champ multi-ligne par une instance du WP Editor. Coincé, ahaha !

« Héritage » utilise en effet un fichier JavaScript monobloc se basant sur la librairie jQuery pour dynamiser ses interfaces. Ce fichier est chargé sur toutes les pages BuddyPress et contient toutes les interactions des différents composants disponibles dans l’extension. Par ailleurs, ces fonctions sont très sensibles au respect du balisage HTML et de l’intitulé des attributs d’identifiant et de classe des différentes balises du pack de gabarits. L’avantage de cette « faiblesse » est que vous pouvez l’exploiter pour proposer une version plus « old school » de l’expérience de publication des activités en changeant par exemple les attributs d’identifiant de certaines balises. Ce faisant, vous déroutez ce JavaScript gargantuesque et ses fonctions de publication sans rechargement de la page grâce à son approche Ajax pour retomber sur un procédé classique de soumission de formulaire avec rechargement de page.

CQFD : en modifiant l’attribut d’identifiant de deux balises (#whats-new-options et #aw-whats-new-submit), le bouton « Publier la note » apparaît et sur son clic : la page est rechargée et l’activité publiée.

Si, à présent, vous vous intéressez au deuxième formulaire : celui généré par « Nouveau », on s’aperçoit que cette étape de modification des attributs de balise n’est pas nécessaire. Vous pourrez en effet directement profiter d’un traitement avec rechargement de la page de vos activités dans le cadre de ce pack de gabarits.

Maintenant, si vous souhaitez garder le comportement dynamique liée à l’approche Ajax, il sera nécessaire de prévoir la création d’un JavaScript pour imiter les codes d’ajout d’activités que chacun des deux packs de gabarits utilisent. Pour plus d’informations sur ce sujet, je vous invite à parcourir le JavaScript du thème enfant que j’ai préparé pour accompagner cet article.

Personnaliser notre WP Editor pour plus de cohérence avec le contexte des activités BuddyPress.

Je crois qu’il est absolument nécessaire d’effectuer cette personnalisation dans la mesure où le balisage autorisé pour le contenu des activités est beaucoup plus restrictif qu’il ne l’est pour les articles ou les pages de WordPress. Pour connaître les balises autorisées pour le contenu de nos activités, il suffit de s’intéresser à la fonction bp_activity_filter_kses() de BuddyPress (ce lien vous permet de la consulter).

Adaptation de la barre des commandes du WP_Editor.

On s’aperçoit qu’il est donc superflu de garder un certain nombre de commandes de notre WP_Editor :

• la liste déroulante pour mettre en forme des titres,
• le bouton pour ajouter des citations,
• les boutons d’alignement de texte,
• le bouton pour ajouter le marqueur « Continuer la lecture »,
• et les boutons pour afficher en plein écran ou encore la barre des commandes avancées.

En revanche, il peut être intéressant de permettre aux utilisateurs de votre site n’ayant pas la capacité de téléverser des fichiers de pouvoir intégrer des images distantes à leur contenu.

Pour parvenir à cette adaptation, il suffit d’utiliser l’API des plugins de WordPress et en particulier sa fonctionnalité de filtre. La cible de notre filtre est mce_buttons et une bonne technique pour éviter d’impacter les autres instances du WP_Editor (notamment celle de l’éditeur classique de vos articles et pages) consiste à précéder l’utilisation de la fonction par l’insertion d’un filtre et d’y succéder le retrait de ce filtre. Je vous invite à observer les lignes 27 et 42 du morceau de code ci-après.

La fonction imath_wp_editor_buttons() est celle qui sera appelée par le filtre en question et grâce à elle nous pouvons désactiver les commandes superflues de notre WP_Editor et lui ajouter la commande d’insertion d’images distantes.

Intégrer le support des mentions BuddyPress

BuddyPress apporte de nombreuses fonctions communautaires pour permettre à vos utilisateurs d’interagir entre eux. L’une d’entre elles consiste à associer un autre utilisateur à votre activité en le mentionnant. Pour cela, vous pouvez vous rendre sur sa page de profil et cliquer sur le bouton « Message public » comme illustré ci-dessous.

Il est également possible, directement depuis le champ multi-ligne de création d’activités de déclencher l’affichage d’une liste d’utilisateurs en initialisant la saisie du caractère @ suivi des premières lettres du nom de l’utilisateur recherché.

Etant donné que nous avons transformé ce champ multi-ligne, il est important de maintenir ces deux fonctionnalités pour les utilisateurs.

Pour la première (le clic sur le bouton d’action du profil de l’utilisateur à mentionner), c’est assez simple puisqu’il s’agit de pré-remplir le contenu de notre WP_Editor en fonction du paramètre $_GET['r'] envoyé dans l’URL. Il contient le nom d’utilisateur de la personne à mentionner, reportez-vous à mon adaptation (ci-dessous) des lignes 6 à 8 de la fonction vue plus haut  imath_activity_editor() .

Pour la seconde, c’est plus complexe car BuddyPress réserve l’intégration de la liste dynamique de choix des utilisateurs à mentionner aux écrans d’édition des articles et des pages WordPress. Il sera donc nécessaire de prévoir un code JavaScript qui assure cette intégration en s’assurant que l’éditeur a bien été complètement initialisé. Le JavaScript du thème enfant qui accompagne cet article intègre cette fonctionnalité, voici les lignes concernées.

Personnaliser l’éditeur de Media pour les utilisateurs ayant la capacité de téléversement de fichiers.

Vous pouvez vous affranchir de cette étape si vous décidez de désactiver l’éditeur de Media qui accompagne le WP_Editor par défaut. Pour cela, il suffit d’éditer le paramètre media_buttons du tableau passé en troisième argument de la fonction wp_editor(). En le fixant à false tout le monde disposera du bouton d’insertion d’images distantes !

S’il vous reste du courage pour aller au bout de cet article, voici ce qu’il me semble important de considérer pour éviter des surprises avec vos utilisateurs ayant des rôles qui intègrent la possibilité de téléverser des fichiers (Administrateur, Editeur et Auteur. Voir plus si vous personnalisez les rôles de WordPress !).

Tout d’abord, comme nous l’avons vu plus haut, le balisage autorisé pour le contenu des activités est plus restrictif que celui des articles et des pages. Et s’agissant des Media : seule la balise img est prise en charge. Il est donc superflu de maintenir le menu latéral de l’éditeur des media qui permet d’insérer des galleries de photos, ou des playlists de vidéos et d’audios. Pour le masquer, il suffit d’ajouter une nouvelle classe intitulée « hide-menu » à l’attribut correspondant de la balise .media-frame . Vous pouvez consulter ces lignes de code pour avoir une meilleure idée sur la manière de réaliser cette opération (en JavaScript) en étant certain que l’éditeur de Media a été initialisé.

Ensuite, il est également important de s’assurer que :

1. seules des images pourront être téléversées,
2. seules des images seront retournées par la bibliothèque de Media du deuxième onglet de l’interface.

Pour y parvenir, il est nécessaire d’ajouter 3 nouveaux filtres. Deux d’entre eux utiliseront la même approche que pour la personnalisation des boutons de la barre de commandes du WP_Editor vu plus haut (ajout avant la fonction wp_editor() et retrait juste après), ils concerneront :

• la personnalisation des types de fichier supportés par la librairie de téléversement utilisée par l’éditeur de Media (Plupload.js) : c’est l’objet de la fonction bp_activity_2017_upload_mimes() du thème enfant qui accompagne cet article.
• la personnalisation des choix disponibles dans la liste déroulante de filtrage par type de l’éditeur de Media : ce même thème utilise pour cela sa fonction bp_activity_2017_mime_types().

Nous retrouvons bien, dans ce thème, l’ajout et le retrait de ces deux filtres portant respectivement sur upload_mimes et post_mime_types autour de la fonction wp_editor() afin qu’ils produisent leurs effets.

Le troisième filtre est à positionner d’une manière plus globale sur le marqueur permettant de personnaliser les arguments de la requête Ajax qui peuple les éléments de la bibliothèque : pour le thème enfant accompagnant l’article, il s’agit de bp_activity_2017_query_attachments_args, comme illustré par ces lignes de code. Etant donné que nous sommes sur un scope plus global, il est primordial de limiter l’action de ce filtre au contexte du composant des activités de BuddyPress, raison pour laquelle la condition bp_is_activity_component() doit être satisfaite pour autoriser la restriction aux images pour la bibliothèque de Media.

Pour faire une respiration, bien méritée, je vous propose la vidéo de démonstration ci-après qui illustre ce qui a été accompli jusqu’à présent.

Enfin, parce que les détails sont importants, il reste un dernier filtre à positionner : celui qui va modifier l’intitulé du bouton principal d’insertion de l’image. En effet, au lieu de « Insérer dans la page » il est plus adapté d’indiquer « Insérer dans l’activité ».

Télécharger le thème enfant

Le bouton ci-dessus vous enverra sur le dépôt GitHub d’un thème prêt à l’emploi qui reprend chacune des étapes décrites dans cet article. Il intègre également des informations passées sous silence comme une feuille de style pour améliorer la présentation du formulaire dans les gabarits des packs « Héritage » et « Nouveau ». Ce thème n’envisage pas tous les cas de figure : j’estime vous avoir montré suffisamment de chemin pour vous permettre de réaliser les ajustements que votre configuration BuddyPress nécessitera. En particulier, le composant des Groupes à partir desquels il est possible de publier des activités n’est pas supporté et le thème vous le fera savoir si vous avez activé ce composant !

Enfin, par rapport au message qui m’a été envoyé via ma page de contact et qui est à l’origine de cet article. Je précise que je ne suis pas un génie sorti d’une lampe qui exhausse des voeux. Je ne crois pas d’ailleurs qu’il existe de telles créatures. Il n’y a que très rarement des « trucs » lorsqu’on souhaite faire les choses consciencieusement : personnaliser à ce niveau BuddyPress (ou WordPress d’ailleurs) nécessite du travail, des recherches, de la formation et donc du temps qu’on n’utilise pas sur autre chose.

Je n’attends rien en retour à titre personnel, cela fait bien longtemps que je me suis fait une raison sur le comportement individualiste des « useurs » de WordPress. Mon espoir est que le lecteur investira en retour de son temps pour le projet open source BuddyPress en participant notamment à sa période de bêta-tests : la version 3.0 de BuddyPress introduira un nouveau pack de gabarits très modernes et il est important d’y contribuer dans cette dernière ligne droite.

La prochaine version majeure de WordPress, la 5.0.0, est dépendante des progrès accomplis concernant l’intégration du projet Gutenberg (contenant notamment l’éditeur moderne). En attendant, les versions mineures à venir peuvent être amenées à intégrer de nouvelles fonctionnalités et ne sont plus seulement des versions de maintenance ou de sécurité. Voici une situation problématique, qui je l’espère perdurera le moins longtemps possible.

Aussi, à la différence des 5 versions mineures qui l’ont précédée, la 4.9.6 introduira des évolutions et des adaptations liées à la mise en conformité de WordPress par rapport à la prochaine entrée en vigueur du règlement général de protection des données (RGPD).

Ok, mais en quoi c’est risqué ?

Tout simplement parce qu’une version mineure bénéficie de la fonctionnalité de mise à jour automatique, et sauf erreur de ma part : ce sera bien le cas pour cette version 4.9.6. Or, si une regression se glisse dans les travaux de l’équipe de développement, vous ne pourrez pas l’éviter et ce risque augmente lorsqu’on travaille sur des évolutions.

Alors, comme le planning de la 4.9.6 prévoit la publication de la première version bêta pour aujourd’hui, le 1er mai 2018 …

Je vous recommande vivement de participer à cette période de bêta-tests et de rapporter tous les comportements inadaptés que vous constateriez sur l’environnement de suivi des versions et des rapports d’anomalie de WordPress.

Pour récupérer cette 4.9.6 bêta 1, je vous invite à surveiller l’annonce qui devrait être faite prochainement sur l’étiquette 4-9-6 du site d’information des contributeurs du Core : make.wordpress.org/core.

Une regression dans l’expérience utilisateur

Si les contributeurs de cette version font un excellent travail sur le thème de la conformité au RGPD (ou GDPR en anglais) – énorme merci à eux – j’ai d’ores et déjà constaté que les adaptations apportées au formulaire de publication des commentaires ont un impact négatif sur l’information des utilisateurs une fois le commentaire envoyé pour modération.

C’est selon moi d’autant plus fâcheux, que ça introduit un déséquilibre quant au niveau d’information fourni à ceux qui autorisent l’utilisation des cookies pour la sauvegarde temporaire de leurs informations personnelles par rapport à celui de ceux qui la refusent.

J’ai évidemment fait part de mon inquiétude avec insistance sur l’environnement dont je parlais plus tôt. Malheureusement, la résolution de cette inquiétude est remise à « si on a le temps ou sinon lors de la prochaine version« .

Impacts possibles de la regression

Dans l’état actuel de la considération du rapport d’anomalie que j’ai remonté, la regression est inévitable pour les administrateurs de site car, je le rappelle, la 4.9.6 est une version mineure qui se met automatiquement à jour. Ce qui est certain, c’est que le visiteur soucieux de ne pas utiliser de cookies sera dans la confusion la plus totale !

Mon commentaire a-t-il été sauvegardé ? Pas certain, allez j’en renvoie un autre l’histoire d’être sûr.. Même résultat, bon j’utilise le formulaire de contact pour avertir l’administrateur de ce site… 

Le visiteur…

Un utilisateur sceptique, ça va. Mais si tous ceux qui commentent le font plusieurs fois, ce qui est probable étant donné que la case à cocher est par défaut inactivée, ça peut vite polluer ! Je n’imagine même pas les cas, sans doute moins nombreux, où l’administrateur utilise un formulaire de commentaire personnalisé au lieu de la fonction comment_form().

Enfin, les développeurs d’extensions liées aux commentaires noteront que la fonction wp_get_current_commenter() qui habituellement renvoie les informations du commentateur non authentifié, pourra renvoyer un tableau de valeurs vides.

Maintenir la même expérience pour tous les commentateurs !

J’espère que le temps restant avant la publication de cette 4.9.6 permettra à l’équipe Core de WordPress de revenir sur cette anomalie. En attendant, comme je vous adore mes chers commentateurs, pas d’inquiétude ! Je ne prends pas de risque grâce à l’extension que j’ai conçue à partir de la rustine partagée sur le rapport d’anomalie

Thème, c’est mon nouveau thème ! Il profite des nouvelles possibilités offertes par l’éditeur moderne du projet Gutenberg pour mettre en forme mes contenus. J’ai profité de ce changement de tapisserie pour revoir et simplifier l’organisation du site.

Exclusivement sur imathi.eu !

Si habituellement je partage volontiers mes « créations WordPress », j’ai préféré me réserver celle-ci et me faire plaisir très égoïstement

J’ai démarré les travaux relatifs à la création et à la mise en place du thème le 21 janvier 2018. Ma première motivation a été de mettre en place des gabarits (ex: single.php) et des règles de style qui permettent de profiter au mieux des nouvelles possibilités d’alignement et d’organisation du contenu en blocs de l’éditeur moderne. Le bloc « image de couverture », ci-dessus, illustre notamment l’alignement « pleine largeur ».

Avec cet article, mon blog WordPress recense 167 articles. S’il n’est pas nécessaire d’effectuer des actions particulières sur les contenus pour l’éditeur moderne, les choix que j’ai fait pour ce thème et les techniques de génération de contenu, m’ont contraint à re-balayer chacun de mes 166 articles précédents.

En effet, j’ai abandonné tous les « shortcodes » que j’utilisais au profit de ma collection de GutenBlocks, il a donc fallu supprimer les vilaines traces que laisse cette technique une fois que la fonction de rappel du shortcode n’existe plus. Et tant que j’y étais, j’ai converti le contenu de ces articles en blocs.

Sur ma lancée, j’ai également revu les media attachés aux articles car j’ai une gestion externe de ces derniers (via Flickr notamment). Je me suis aperçu que j’avais fait un très mauvais choix concernant l’un de ces services pour mes premiers articles (Photobucket). Il m’affichait des placeholders dégueulasses au lieu de mes images ! J’ai donc récupéré l’intégralité de mes images (avant de supprimer mon compte) pour les ré-attacher aux contenus endommagés.

J’ai achevé ces besognes en corrigeant mes niveaux de titre qui étaient parfois très fantaisistes. L’outil fournit par l’éditeur du projet Gutenberg m’y a beaucoup aidé.

Un menu tout simplement.

Le menu supérieur organise la navigation du site, je fais en effet l’économie de la barre latérale (sidebar) qui proposait jusqu’à présent des widgets pour filtrer mes articles par étiquette, catégorie ou encore selon des termes recherchés. Les catégories sont désormais des sous-menus du menu « Le blog » et si vous êtes des « sidebar » nostalgiques, vous pourrez toujours retrouver des widgets depuis le sous-menu « Rechercher » du même menu.

Une confirmation plus explicite de la prise en compte de vos commentaires

C’est un point qui me tient énormément à coeur. En effet, même si de nos jours la plupart des conversations interviennent sur les media sociaux, la fonctionnalité de réaction à un article à l’aide d’un commentaire reste une formidable contribution pour les prochains lecteurs. Mon attachement à cette fonctionnalité explique ma sidération quant à la perte de considération que les auteurs de commentaire subiront (par défaut) une fois que la prochaine version mineure (4.9.6) de WordPress se sera répandue. Pour en savoir plus, je vous invite à (re)lire ma grande inquiétude sur ce sujet. 

Voici pourquoi, j’enfonce le clou (malgré les railleries de certains qui minimisent cette importante régression) : que les auteurs de commentaire acceptent ou non l’utilisation de cookies, leur considération doit être la même.

Ainsi, comme je l’explique dans l’article, pour me permettre de maintenir ce niveau d’information pour chaque auteur de commentaire sur ce site, j’utilise l’extension que j’ai créée à partir de la rustine partagée sur ce ticket de l’environnement Trac du core de WordPress. Ticket dont la résolution a été remise à plus tard, je n’en reviens toujours pas !

Pour information, il existe une technique plus radicale qui consiste à désactiver cette fonctionnalité de consentement d’utilisation des cookies que l’équipe de développement du Core de WordPress prévoit de forcer sur vos sites avant de résoudre la régression qu’elle introduit.

Voilà ! Je vous passe les aménagements du Customizer que je me suis concocté pour personnaliser ma page de connexion à l’administration, ma page d’erreur de connexion à la base de données du site et mon gabarit pour les notifications e-mail de WordPress.

J’espère que ce nouveau papier peint vous plaira. A+.

« Apollo » c’est le surnom de la version 3.0.0 de BuddyPress, une version qui célèbre les 10 années d’existence de l’extension de WordPress qui vous assiste dans la construction de votre site communautaire.

Une des évolutions introduites concerne le « templating » de votre site communautaire puisque « Nouveau », un pack de gabarits modernisés propose désormais une alternative à celui qui avait été hérité du thème « BP Default » au moment du lancement de l’API de compatibilité avec les thèmes WordPress (version 1.7). « BP Legacy », c’est son nom, reste donc disponible et activé par défaut pour les sites qui mettrons à jour BuddyPress et « Nouveau » le sera pour les toutes nouvelles installations de l’extension.

Notez que depuis l’écran d’administration des options de BuddyPress, vous pouvez à tout moment activer l’un ou l’autre des packs selon vos préférences.

Nouveau

L’histoire de ce pack au nom très français a débuté il y a plus de 2 ans, j’avais à l’époque initié des travaux de rénovation au niveau de JavaScript en rendant l’énorme buddypress.js beaucoup plus modulaire et en m’appuyant sur la librairie Backbone.JS qui reste à ce jour la seule embarquée dans le Core de WordPress pour presqu’organiser en Modèles/Vues/Contrôleurs notre code. Ça évoluera très certainement avec la probable intégration de React au Core de WordPress lors de sa version 5.0, d’autant que Backbone.JS est scotchée en version 1.3.3 depuis avril 2016…

Toutefois, grâce à Backbone.JS, il a été possible de dynamiser certaines interfaces utilisateur en les transformant en « SPA » (Application Web Monopage). Le formulaire de création des Activités, l’interface d’invitation des Groupes et l’interface des Conversations Privées sont les premières applications de ce procédé dans BuddyPress.

La construction d’un tel ensemble de gabarits est selon moi super complexe (car il s’agit de maximiser l’intégration des contenus BuddyPress dans la majorité des thèmes WordPress) et est très consommatrice d’énergie. Aussi, je tiens à féliciter l’équipe de développement de BuddyPress et plus particulièrement Hugo Ashmore qui a joué un rôle primordial dans la réussite de ce tour de force.

Cette intégration de « Nouveau » au Core de BuddyPress sera très bénéfique à ce nouveau pack de gabarits car il sera beaucoup plus facile pour les contributeurs de le tester et de remonter d’éventuelles anomalies ou évolutions.

Injecter du sang neuf dans l’héritage !

Cette première partie contextuelle posée, venons en à l’objet principal de cet article. Comme certainement beaucoup d’entre vous, il se trouve que pour l’un des sites dont je m’occupe, je n’ai pas encore eu la possibilité de reporter les adaptations que j’ai apportées au fil des années au pack de gabarits « Legacy » dans « Nouveau ».

Toutefois, je suis hyper intéressé par sa nouvelle interface d’envoi d’invitations à rejoindre les groupes. Je me suis donc amusé à faire évoluer ma vieillissante extension WorkMates pour qu’elle me permette d’utiliser cette nouvelle interface très prometteuse dans « Legacy ».

Pour maintenir l’intégralité des fonctions de la première version de WorkMates, j’y ai ajouté la possibilité de filtrer la liste des membres potentiels selon leur type (j’utilise en effet la fonctionnalité type de membre de BuddyPress pour mon site). Par ailleurs, j’ai enrichi, sans le moindre effort, WorkMates d’une navigation « Mes amis » afin de laisser la possibilité à ceux qui activent ce composant de permettre à leurs utilisateurs de ne lister que les amis qui ne sont pas encore inscrits dans le groupe. C’est quelque chose qui m’avait été demandée dans ce rapport d’évolution.

Pour en savoir plus au sujet du fonctionnement de cette interface d’envoi d’invitations à rejoindre un groupe, je vous invite à parcourir la page du Codex de BuddyPress qui s’y rapporte.

Téléchargement

WorkMates 2.0.0

Requiert la version 3.0.0 de BuddyPress

Afficher la page GitHub de la version

Télécharger la version 2.0.0

L’environnement « develop » de WordPress a dernièrement évolué pour améliorer la modularité et la flexibilité de ses JavaScripts, préparer l’arrivée prochaine de l’éditeur du projet Gutenberg et favoriser le recours aux pratiques JavaScript modernes. Je vous invite à prendre connaissance de l’article ci-dessous pour en savoir plus sur le sujet.

Si comme moi, vous avez pris vos aises dans cet environnement pour développer vos extensions, vous avez certainement vu ce message informant qu’il est désormais obligatoire de « construire » WordPress.

Il est donc nécessaire, pour élaborer ce build, d’installer Node, NPM, Grunt et les modules Node que WordPress utilise pour automatiser les travaux qu’implique cette construction. Pas de souci de mon côté puisque pour contribuer à BuddyPress, Gutenberg et fabriquer mes extensions, je suis déjà équipé en conséquence.

En passant, là où un espace disque de 48Mo suffisait pour contribuer à WordPress, la partie immergée liée aux modules Node et à la mise en place de ce build requiert désormais pratiquement 230Mo de plus. Il faudra penser à prendre en compte cette nouvelle contrainte dans l’organisation des contributor days…

L’impact le plus important porte sur la volatilité de ce build. Car en effet, ce que nous mettions dans src/wp-content/plugins peut très simplement être déplacé dans build/wp-content/plugins une fois ce dernier constitué. Cependant, grunt build démarre par une suppression totale du dossier build avant de le reconstituer. Voilà pourquoi l’utilisation des liens symboliques que je pratique depuis un bon moment pour mon confort s’impose désormais pour garder en efficacité.

Je range toutes les extensions que je crée, utilise ou auxquelles je contribue dans un dossier complètement en dehors de toute arborescence de site : dans un répertoire « plugins » de mon « home »  ~/plugins. Ensuite, jusqu’à présent je créais un lien symbolique vers une ou plusieurs de ces extensions en jouant depuis ~/Sites/wp-develop/src/wp-content/plugins (par exemple) ce type de commande :

ln -s ~/plugins/entrepot entrepot

Il s’agit donc de se positionner désormais sur ~/Sites/wp-develop/build/wp-content/plugins après chaque grunt build pour continuer à pouvoir tester visuellement dans le navigateur nos développements personnels.

No problémo lorsqu’il s’agit de le faire pour une extension, mais à partir de deux ça commence déjà à être un peu plus chiatique ! Du coup je me suis construit le script bash ci-dessous pour automatiser un peu cette tâche devenue beaucoup plus répétitive.

J’insère ce fichier build.sh dans ~/Sites/wp-develop/tools en veillant à le rendre transparent grâce à un .gitignore une bonne fois pour toute, et au lieu de jouer le grunt build  je joue ./tools/build.sh qui le contient (cf. ligne 19) en plus de la génération automatique des liens symboliques pour la liste des extensions présentes dans mon ~/plugins de mon choix. Si vous souhaitez vous aussi profiter de cette astuce, voici comment la mettre en place :

# Se potionner dans le répertoire tools
cd chemin_vers_WordPress_develop/tools

# Ajouter un .gitignore dans le répertoire
# tools pour que le script bash soit ignoré.
touch .gitignore
echo 'build.sh' >> .gitignore

# Télécharger puis placer le ficher build.sh dans
# le répertoire tools avant de le rendre exécutable.
chmod +x build.sh

# Remonter à la racine du site.
cd ..

# Récupérer les derniers commits WordPress.
# PS: j'utilise le miroir Git du repo SVN.
# Voir https://make.wordpress.org/core/2014/01/15/git-mirrors-for-wordpress/  
git pull

# Lancer le build en spécifiant les liens
# symboliques à créer une fois le build accompli
# dans l'invite qui s'affichera.
./tools/build.sh

Une nouvelle version de l’extension WordPress qui organise vos media publics et privés est disponible ! Cette 1.2.0 contient des adaptations aux dernières évolutions de l’éditeur moderne du projet Gutenberg et une amélioration quant à la gestion de l’affichage des fichiers PDF publics.

Rafraîchissement du bloc MediaThèque.

Introduit lors de la version 1.1.0 de l’extension (pour la version 1.8.0 de Gutenberg), il avait bien besoin d’un bon rafraîchissement pour s’adapter aux nombreuses évolutions apportées depuis à l’éditeur moderne de WordPress (sa version actuelle est la 3.0.1).

Les PDF publics s’affichent dans vos contenus.

Suite au message très enthousiaste de l’un d’entre vous au sujet de cette extension, et à sa juste suggestion : une nouvelle préférence d’affichage à été ajoutée pour les fichiers PDF. Elle repose sur la fonctionnalité des navigateurs qui proposent pour la plupart un dispositif afin d’afficher ce type de fichier (j’ai vérifié que c’était bien le cas sur Chrome, Firefox, Edge et Safari).

Si toutefois le navigateur de votre utilisateur est vieillot, il bénéficiera de l’affichage classique du fichier (un lien plus ou moins mis en forme).

Pour profiter de cette amélioration, il s’agira d’éditer les préférences d’affichage du media une fois inséré dans votre contenu.

En cliquant sur l’icône en forme de crayon de votre bloc MediaThèque, la fenêtre ci-dessous s’affichera et vous n’aurez plus qu’à activer la case à cocher « Incorporer le media » pour que votre fichier PDF public le soit !

Si vous n’utilisez pas encore l’éditeur moderne de Gutenberg (boooo !), l’éditeur classique vous proposera également un menu contextuel lorsque vous cliquerez sur votre media.

Mettez à jour vos MediaThèques !

Vous utilisez l’Entrepôt, bravo ! Foncez dans votre Administration WordPress pour directement déclencher cette mise à jour ou son installation en quelques clics.

Pour les autres (boooo 2 !), il faudra le faire à l’ancienne en téléchargeant la version 1.2.0 depuis ce lien et en téléversant l’archive ZIP récupérée dans votre interface WordPress d’ajout manuel d’extension.

MediaThèque

Requiert WordPress 4.7. Testé jusqu’à WordPress 5.0

Afficher la page GitHub de la version

Télécharger la version 1.2.0

Votre source alternative d’extensions WordPress gratuites, open source et hébergées sur GitHub poursuit son évolution et propose à l’occasion de cette nouvelle version majeure (1.4.0) de vous équiper d’une nouvelle source de thèmes WordPress gratuits, open source et hébergés sur GitHub.

Cette nouvelle évolution fonctionne d’une manière équivalente à la fonctionnalité qui se charge des extensions tout en s’adaptant aux spécificités des vues Backbone.JS qui dynamisent l’interface de personnalisation et d’administration des thèmes.

L’Entrepôt, une alternative dans laquelle chacun est maître de son « chez soi ».

D’abord conçu en réaction à l’évolution (de moins en moins orientée vers la contribution et les développeurs et de plus en plus orientée vers la promotion d’extensions « à finalité marchande » et les clients) du répertoire officiel des extensions WordPress, l’Entrepôt répond à mes besoins de partage et d’encouragement de la contribution à mes travaux.

Cet espace d’entreposage est ouvert à tous les auteurs d’extensions et désormais de thèmes hébergés sur GitHub qui souhaitent simplifier la vie de leurs utilisateurs afin d’installer et maintenir à jour leurs extensions et thèmes.

L’Entrepôt, du confort pour les utilisateurs et les développeurs.

Ensuite, au fil de ses versions, l’Entrepôt intègre également des fonctionnalités accessoires telles que :

• La fourniture d’un centre de notifications pour organiser les alertes que les extensions ou thèmes peuvent générer dans la partie haute de vos pages d’administration et qui parfois abusent de cette possibilité.
• Une gestion manuelle (Upgrade ou Downgrade) des versions des extensions installées dans votre WordPress.
• Les développeurs peuvent également se reposer sur son API de gestion des tâches de mise à jour des extensions ou des thèmes pour organiser et déclencher ces tâches sereinement lorsque celles-ci vont au delà de la simple actualisation de la version installée dans la table des options du site WordPress.

Auteurs de thème(s) : rejoignez l’Entrepôt !

Pour partager vos thèmes gratuits, open source et hébergés sur GitHub, il vous suffit de faire une Pull Request contenant un fichier descriptif de votre thème et d’intégrer un marqueur spécifique dans le fichier style.css de votre thème. Pour en savoir plus, je vous invite à parcourir la documentation de l’Entrepôt.

Je serais enchanté de voir se remplir l’écran ci-dessous pour que l’Entrepôt propose un choix plus intéressant que mon modeste thème enfant de TwentySeventeen.

Les utilisateurs de l’Entrepôt pourront alors installer et activer votre thème en quelques clics depuis l’interface d’ajout de thèmes de leur administration ou directement depuis leur Customizer comme illustré ci-après.

Par la suite, si vous publiez de nouvelles versions de votre thème, les utilisateurs en seront informés directement depuis leur administration comme tout thème hébergé sur WordPress.org. Ils pourront alors, d’un simple clic, se maintenir à jour.

Administrateurs de site(s) : devenez utilisateurs de l’Entrepôt !

Faites une place à cette source alternative d’extensions et de thèmes gratuits et open source et contribuez à leur développement sur GitHub.

Si vous ne l’avez pas encore adopté, le lien ci-dessous est à votre disposition. Pour les autres, vous serez très vite informés de la disponibilité de cette mise à jour depuis votre Administration WordPress.

Entrepôt 1.4.0

Nécessite WordPress 4.8 ou versions ultérieures.

Afficher la page GitHub de la version

Télécharger la version 1.4.0