La prochaine version majeure de BuddyPress revoit complètement la manière dont l’extension génère ses liens et analyse l’URL demandée par un·e utilisateur·rice en vue de déterminer s’il s’agit d’une page de l’espace communautaire du site (ou autrement dit : comment elle gère le routage des URL).
Après dix années de travaux et d’hésitations, avec l’équipe nous avons finalement décidé de migrer vers l’API de réécriture d’URL de WordPress. Si, persuadé que c’est une excellente décision pour la fiabilité du système de routage des URL de BuddyPress, j’ai fortement insisté sur le sujet depuis deux ans : je mesure le risque que cette évolution fait peser sur le projet open-source dans son ensemble.
C’est pourquoi en plus des mesures de mitigation qu’au sein de l’équipe de développement nous mettons en œuvre, je partage avec les auteur·rice·s d’extensions de BuddyPress qui comprendront l’importance de s’assurer de leur compatibilité avec la version 12.0.0 ce modèle d’Add-on en guise de coup de pouce.
Tranquillité de l’immobilisme VS risque d’isolement liée à une évolution de rupture.
Sans hésitation, je choisis le changement, le mouvement, bref la vie !
La version 12.0.0 de BuddyPress marque, suite à quinze années de relative stabilité, la première étape d’une redéfinition progressive de son rôle, de son organisation et de ses apports pour les propriétaires d’un site WordPress. Cette volonté de forte évolution est née de l’analyse de l’appel à feedbacks que le projet open-source a lancé à la fin de l’année 2021 en réaction à une diminution spectaculaire du nombre de sites WordPress étant équipés de BuddyPress.
Avec le recul, je crois personnellement qu’en voulant nous positionner comme un cadre de fonctions et d’API communautaires élémentaires permettant à d’autres extensions de proposer des fonctionnalités plus abouties, nous nous sommes progressivement emprisonnés dans une situation où la moindre évolution qui se voit un peu soulève une levée de boucliers des développeur·euse·s d’extensions. L’argument utilisé, celui qui me hérisse le peu de cheveux qu’il me reste, est généralement « It’s plugin territory » ou autrement dit : n’intégrer pas cette évolution car elle relève du territoire des extensions.
Revers de la médaille : lorsqu’on s’intéresse aux utilisateur·rice·s, il est souvent reproché à BuddyPress de ne pas intégrer les fonctionnalités essentielles attendues d’un logiciel visant à créer des communautés en ligne. Ils·elles n’ont alors pas d’autres choix que de se procurer des extensions additionnelles pour concrétiser leur projet de site communautaire. Si c’est plutôt cohérent avec le positionnement que nous souhaitions donner à BuddyPress jusqu’à présent, ça devient vite très problématique lorsque ces extensions additionnelles ne sont plus mises à jour…
Ce qui est malheureusement monnaie courante et qui affaiblit l’intérêt des utilisateur·rice·s pour BuddyPress 😖. Il faut sortir de ce cercle vicieux !
En complément de cette relative inertie qui semble régner dans le « territoire » des extensions de BuddyPress, j’ai assez vite compris que l’évolution de notre système de routage des URL accentuerait considérablement notre différence par rapport à un dérivé (« fork ») de BuddyPress utilisé par ses auteur·rice·s (« buddybouses » 💩) pour enfermer celles et ceux qui succombent à leurs arguments publicitaires dans la nécessité d’acheter leurs produits payants pour continuer à bénéficier d’un support.
En passant, contrairement à ce que cet article laisse entendre, « buddybouses » 💩 n’est pas la version payante de BuddyPress :
- Il n’y a qu’une seule version de BuddyPress, l‘authentique, elle est et demeurera gratuite (tout comme son support), open-source et disponible sur le répertoire officiel des extensions de WordPress.
- le code forké par « buddybouses » 💩 reste open-source et gratuit, ce qui est payant ce sont les autres services proposés par leurs auteur·rice·s (thème, application mobile, et indirectement le support puisqu’il faut être client pour en bénéficier…).
Le problème « buddybouses » 💩
Si j’écorche volontairement le nom de cette extension en la comparant à de l’excrément de vache, ce n’est pas en raison de la qualité de son code (comme c’est un dérivé de BuddyPress, elle reprend du code que moi ou mes amis de l’équipe de développement de BuddyPress avons jadis écrit) ou de ses fonctionnalités ni même de mon énorme déception par rapport au choix de ses auteurs – que j’avais croisés en 2015 à Brighton – de ne plus contribuer à BuddyPress et d’avoir préféré diverger par pur appétit commercial, mais c’est parce que leur choix a eu des effets « merdiques » pour les utilisateur·rice·s. Lorsqu’il y a beaucoup de confusion, ne dit-on pas « c’est la merde ! » ?
En effet, il est fréquent que certain·e·s utilisateur·rice·s du dérivé, probablement pour éviter de payer pour ses offres satellites premium, s’adressent au support de BuddyPress. Or comme nos codes ont divergé, répondre à ce type de demande c’est prendre le risque d’empirer leur situation. Nous générons donc malgré nous de l’insatisfaction.
Et surtout, certains utilisateur·rice·s du dérivé activent également des extensions de BuddyPress sur leur configuration divergente, ce qui pour les auteur·rice·s de ces extensions complexifie leurs travaux de maintenance et de support. Personnellement, je ne souhaite pas prendre le risque que les extensions de BuddyPress que je partage soient installées sur un site WordPress utilisant un dérivé de BuddyPress, raison pour laquelle j’utilise cette méthode de contrôle pour m’en assurer (dans l’attente de la fusion de la fonctionnalité de gestion des dépendances dans WordPress).
Je pense que la majorité des auteur·rice·s d’extensions ne prête pas plus d’attention que cela au fait qu‘ils·elles peuvent apporter un correctif prévu pour fonctionner dans BuddyPress alors qu’il pourrait générer des erreurs avec son dérivé ou encore qu‘ils·elles contribuent, malgré eux·elles, au business des auteur·rice·s de « buddybouses » 💩 au lieu du développement du projet open-source BuddyPress.
En revanche d’autres auteur·rice·s d’extensions, payantes notamment, j’imagine pour maximiser leurs revenus, choisissent volontairement de profiter des deux mondes. C’est ce dont j’ai pu me rendre compte lors de mes travaux de migration en faveur de l’utilisation de l’API de réécriture de WordPress durant le cycle de développement de la 12.0.0 de BuddyPress. L’un d’entre eux m’a gentiment fait comprendre que ça serait mieux que j’arrête les frais car autrement je serais celui à blâmer par rapport à l’abandon par les développeurs d’extensions du support de BuddyPress au profit d’autres plateformes plus stables.
En réalité, j’ai compris que mon approche exclusivement motivée par l’intérêt général du projet BuddyPress entrait en conflit avec son intérêt strictement personnel de pouvoir continuer à profiter des deux mondes à moindre coût…
Alors, c’est quoi le risque au juste ?
Si les auteur·rice·s d’extensions de BuddyPress ne revoient pas leur code pour s’assurer qu’elles continuent de s’exécuter de manière optimale dans la version 12.0.0 de BuddyPress, les utilisateur·rice·s risquent de constater de nombreuses alertes de dépréciation. En soit, ça ne me paraît pas plus problématique que cela : c’est au contraire utile aux auteur·rice·s d’extensions pour identifier les fonctions qu’ils ne faut plus utiliser tout en informant de celles qui les remplacent. Si le fichier de configuration de WordPress est bien paramétré, elles n’apparaissent que dans le journal des erreurs.
Beaucoup plus gênant, certaines de leurs extensions de BuddyPress actives ne se comporteront plus comme attendu ou encore ne fonctionneront plus du tout. Étant donné que ce constat interviendra après la mise à niveau de BuddyPress pour sa version 12.0.0 ces utilisateur·rice·s désigneront BuddyPress coupable et feront part de leur mécontentement. Or, une des responsabilités d’un·e auteur·rice·s d’extensions n’est-elle pas de s’assurer de sa compatibilité avec ses dépendances ?
Par ailleurs « buddybouses » 💩 pourrait bénéficier de l’inertie des extensions de BuddyPress gratuites combiné au potentiel choix délibéré de certaines autres payantes de ne pas faire l’effort de mettre à niveau leur code pour grignoter un peu plus notre part d’installations actives. Je doute en effet que les auteur·rice·s de « buddybouses » 💩 prennent immédiatement le risque de copier une nouvelle fois notre code et en particulier notre BP Rewrites API…
Je suis très concerné par cette deuxième éventualité, dans la mesure où malgré les nombreuses communications de BuddyPress sur le sujet, je constate que quasiment aucun·e auteur·rice d’extensions ne nous a rapporté des anomalies alors que nous approchons de la fin de la période de bêta tests de la version 12.0.0 (la version candidate devrait être mise à disposition très prochainement).
Aussi, avant de vous faire part de la manière dont avec l’équipe de BuddyPress nous comptons réduire ce risque, j’encourage les utilisateur·rice·s désireux·euses de contribuer au maintien du projet open-source BuddyPress de massivement contacter le support de leurs extensions pour pousser leurs auteur·rice·s à agir dans l’intérêt général de la communauté.
C’est en effet essentiel pour nous permettre d’aborder en toute confiance les prochaines étapes de la redéfinition de BuddyPress comme étant l’extension vous permettant de vous réunir dans WordPress, selon vos règles et en toute sécurité.
Les mesures de mitigation du risque
La compatibilité arrière de BuddyPress est une de nos plus fortes préoccupations. Rester compatible avec 5 à 6 versions antérieures de WordPress ou avec PHP 5.6 nous demande parfois beaucoup de sacrifices par rapport aux fonctionnalités que nous envisageons d’intégrer. Il en va de même pour les thèmes et extensions qui choisissent d’ajouter une dépendance à notre cadre de fonctions et d’API. Nous sommes donc à la fois vigilants par rapport à nos dépendances ainsi que vis-à-vis des thèmes et extensions qui déclarent une dépendance à BuddyPress.
C’est pourquoi nous avons commencé par empaqueter notre BP Rewrites API dans un « Add-on » en espérant que les auteur·rice·s d’extensions soient proactif·ve·s et nous aident à aborder cette évolution nécessaire le plus souplement possible. Si une très courte minorité a joué le jeu, ça n’est malheureusement pas représentatif de l’ensemble des extensions qui déclarent leur dépendance à BuddyPress (501) en intégrant l’étiquette correspondante dans leur fichier readme.txt ou de l’ensemble des thèmes (64) faisant de même en ajoutant cette étiquette dans leur fichier style.css.
Après 2 années de très faible activité contributive, nous avons finalement décidé de forcer son intégration au cœur de BuddyPress, car malheureusement comme dans beaucoup d’autres domaines, ce n’est qu’une fois au bord du précipice que nous nous adaptons.
Action de maîtrise n°1 : publier une nouvelle extension pour veiller à la compatibilité arrière.
WordPress a été une bonne source d’inspiration sur ce point. De la même manière que vous pouvez restaurer l’éditeur classique de WordPress ou l’écran d’administration des Widgets classiques en activant respectivement Classic Editor et Classic Widgets, vous pouvez revenir au système de routage des URL initial de BuddyPress en activant BP Classic.
En rendant disponible cette extension, BuddyPress retrouve une liberté d’action beaucoup plus forte pour poursuivre sa redéfinition au rythme que son équipe de développement peut impulser tout en donnant aux utilisateur·rice·s plus de temps pour s’habituer aux évolutions ainsi qu’en leur offrant une solution efficace pour gérer leur adhérence aux extensions de BuddyPress qui sont dépassées.
Nous avons par ailleurs optimiser l’usage de cette extension en y déplaçant du code déprécié comme le thème BP Default ou les widgets classiques de BuddyPress. Cette extension a par ailleurs bénéficié des apports de l’équipe Meta de WordPress puisqu’elle équipe le site de nos profils sur WordPress.org.
Ainsi, les utilisateur·rice·s qui ont activé des extensions ou Add-ons de BuddyPress qui ne sont pas maintenus par son équipe de développement (qui a effectivement et bien entendu tenus à montrer l’exemple en s’assurant de la compatibilité de ses extensions avec la version 12.0.0 de BuddyPress) peuvent dés à présent activer BP Classic pour se prémunir de tout risque lors de la prochaine montée de version de BuddyPress (12.0.0).
Il en va de même pour celles et ceux qui font confiance à notre thème ancestral BP Default pour la mise en forme de leur site communautaire ou qui souhaitent continuer de profiter des widgets classiques de BuddyPress.
Action de maîtrise n°2 : donner plus de temps aux auteur·rice·s d’extensions pour mettre à niveau leur code
Nous avons allongé le cycle de développement de la version 12.0.0 et en particulier sa période de bêta tests à 3 mois. Chacune des pré-versions (beta1, beta2, beta3) que nous avons publiées a été une nouvelle occasion de rappeler aux utilisateur·rice·s et aux auteur·rice·s d’extensions l’importance de vérifier que la version 12.0.0 de BuddyPress se comporte de manière optimale dans leurs configurations ou avec leur code. Pour cela il leur suffit de nous alerter dés qu’ils constatent une anomalie.
Action de maîtrise n°3 : documenter les changements à apporter pour aider les auteur·rice·s d’extensions à effectuer cette mise à niveau.
La documentation de BuddyPress repose jusqu’à présent sur un modèle « wiki » dans lequel chaque membre de la communauté peut y contribuer. Ce modèle s’est essoufflé au fil des années, ce qui fait que la plupart des contenus sont dépassés ou mal chapitrés. Aussi, par rapport à l’échec que l’équipe a connu, en février 2022, concernant sa vaine tentative de redéfinition de cette documentation, j’ai réfléchi à un moyen rapide pour diffuser les ressources d’aide importantes et nécessaires à l’accompagnement des changements majeurs introduits par la version 12.0.0 de BuddyPress, en général, et de son API de réécriture, en particulier.
L’idée était la suivante : plutôt que d’essayer de recréer un site WordPress sur le réseau de sites de BuddyPress.org (comme nous l’avions imaginé en début d’année 2022) pour l’équiper de tout un tas d’extensions afin de pouvoir y travailler de manière collaborative, profitons de l’outil collaboratif que nous utilisons pour le code (GitHub) et mettons en place une gestion de la documentation proche de celle du projet Gutenberg de WordPress en l’incluant directement dans le répertoire du code de notre projet open-source. Cette gestion repose sur une seule extension : « Handbook », laquelle, grâce à un paramétrage particulier, permet de synchroniser le contenu d’un dossier de notre répertoire sur GitHub avec des pages d’un site WordPress.
Après m’être assuré d’obtenir un résultat équivalent à la documentation sur le développement de blocks en concevant rapidement cet utilitaire, j’en ai parlé à l’équipe et nous avons décidé de mettre en œuvre l’idée. Les bénéfices immédiats de cette solution sont nombreux :
- Nous pouvons directement utiliser les ressources publiées dans le dossier docs de notre répertoire GitHub et y faire référence dans nos communications.
- Nous construisons au fur et à mesure la documentation et pouvons en parallèle progresser sur la mise en place d’un site WordPress pour la rendre encore plus accessible aux utilisateur·rice·s, le contenu sera quoiqu’il arrive automatiquement synchronisé.
- Nous démontrons que nous considérons la documentation comme aussi importante que le code puisque nous l’y intégrons.
- Nous pouvons créditer les contributeur·rice·s à la documentation de la même manière que celles·ceux qui contribuent au code.
- Nous pouvons les distinguer en générant un badge de contribution à BuddyPress sur leur profil WordPress (Ce sont les « props » ajoutées à nos messages de validation des modifications du code – et désormais de la documentation hébergée dans notre code – qui déclenchent cet ajout).
- J’ai pu mettre à disposition des ressources d’aide pour expliquer comment mettre à niveau une extension pour qu’elle continue de s’épanouir dans la version 12.0.0 de BuddyPress.
Action de maîtrise n°4 : un modèle d’Add-on de BuddyPress prêt pour sa version 12.0.0
Cette dernière action est une initiative personnelle et même si à ce jour elle ne démontre pas tout ce qu’on peut accomplir avec BuddyPress, au moins, elle explique comment bien utiliser ses principales API en tenant compte des apports de la BP Rewrites API.
A BuddyPress Add-on example. Contribute to imath/bp-custom-addon development by creating an account on GitHub.
En résumé et pour conclure
La version 12.0.0 de BuddyPress introduit un changement de rupture pour lequel, malgré nos efforts de communication sur le sujet depuis 2 ans, les extensions de BuddyPress que vous utilisez peuvent ne pas avoir opéré les travaux de mise à niveau nécessaires. L’équipe de développement de BuddyPress est consciente des difficultés que cela peut occasionner dans la gestion de votre site communautaire et a déployé des actions de maîtrise du risque lié à cette évolution de rupture. Cette évolution est importante pour l’avenir de BuddyPress et la redéfinition progressive de la manière dont BuddyPress vous aide à organiser votre communauté dans votre site WordPress en toute sécurité et selon vos propres règles.
En attendant la prochaine mise à disposition de cette version 12.0.0, je vous recommande, si vous avez activé des extensions de BuddyPress non maintenues par l’équipe de développement de BuddyPress, d’installer et d’activer dès à présent l’Add-on BP Classic pour vous prémunir de toute conséquence néfaste pour l’expérience d’utilisation des membres du site de votre communauté.
Je vous encourage, enfin, de prévoir de sauvegarder la base de données ainsi que le répertoire /wp-content de votre site d’ici à la fin octobre et/ou avant d’effectuer la montée de version de BuddyPress depuis l’administration de votre site WordPress.