Voici le récit de mon dernier week-end! La conception d’un plugin expérimental pour enrichir le composant « Groups » de BuddyPress d’une « WordPress built-in » taxonomie. Oh but wait! Ce composant n’est pas un Custom Post Type??!?
Dans le cadre d’une communauté professionnelle positionnée au niveau « Groupe » d’une entreprise, le composant Groupes de BuddyPress s’avère très intéressant pour proposer aux membres de créer des « micro » communautés (ou tribus) réunissant par exemple les collaborateurs de telle ou telle filiale ou de telle ou telle filière. La plupart du temps, j’observe que le choix d’une visibilité privée est privilégiée par les créateurs de ces « tribus ».
L’avantage de ce niveau de visibilité d’un groupe BuddyPress (par exemple) est que le groupe est référencé dans l’annuaire des groupes tout en réservant son contenu aux seuls membres de ce groupe. Les visiteurs ne verront que le titre du groupe, sa description et son équipe d’administration et de modération.
Toutefois, il peut manquer une information importante : « Suis-je le bienvenu dans ce groupe ? ». Autrement dit, « si je demande à adhérer au groupe, son administrateur m’acceptera-t-il ? » Même si certaines descriptions peuvent contenir des informations à ce sujet, tous les créateurs de groupe ne pensent pas forcément à indiquer dans leur description « ce groupe est réservé aux collaborateurs de telle filiale ou de telle filière ».
Il se trouve que dans ma vie professionnelle, j’ai l’opportunité de participer à une expérimentation sur l’utilisation d’une solution de réseau social d’entreprise en mode « SaaS ». Cette solution propose des groupes, mais il semble que la fonctionnalité est incomplète sur un point par rapport à l’utilisation qui en est faite. Pour indiquer qu’un groupe est réservé à telle population, le nom des groupes est préfixé d’un sigle du type « DMKG_ » voulant dire « groupe réservé aux collaborateurs de la direction marketing » par exemple.
Je qualifierais cette pratique de « système D » confusant. Car en effet un nouvel entrant dans la communauté voit son expérience complexifiée de la lecture d’un dictionnaire des préfixes d’une part et le filtrage sur une « étiquette » en particulier me paraît peu intuitive car il s’agit d’utiliser la recherche. Mais à défaut de mieux..
Toujours dans ce cadre, je suis en cours d’itération sur un projet de communauté moins large et plus ciblée mais qui partage le même besoin « d’étiquetage » des groupes. Pour ce prototype j’utilise WordPress et BuddyPress. La grosse différence par rapport à la solution « SaaS », c’est qu’il est très simple d’ajouter ce type de fonctionnalité car le code est ouvert et facilement extensible. On peut même trouver un plugin prêt à l’emploi sur le repository officiel de WordPress (BP Group Tags). J’aurai pu, bien entendu, utiliser ce plugin.
J’ai rapidement parcouru son code source pour me faire une idée. Mon seul problème par rapport à ce plugin est conceptuel. En effet, il s’appuie sur des « groupmetas » pour construire sa fonctionnalité « d’étiquetage » (ou tagging). De mon point de vue, les groupmetas sont des informations servant à qualifier un groupe plutôt qu’à le classer. Je dois reconnaître, toutefois, que c’est le premier endroit auquel j’avais pensé vendredi dernier lorsque mon collègue m’a soumis ce fort besoin de « rangement » des groupes pour notre prototype.
Bien entendu, on aurait également pu reproduire le « système D » évoqué plus tôt. Mais vous l’aurez compris, je ne suis pas favorable à cette solution qui ne me semble pas être maintenable sur la durée. Alors j’ai cogité, recherché, me suis lancé dans une exploration plus profonde de ce que beaucoup d’entre vous connaissent : les taxonomies de WordPress.
Une « vraie » taxonomie non hiérarchique (tag) pour les groupes BuddyPress
Dans WordPress il est possible de créer de nouvelles taxonomies. Pour cela on utilise la fonction register_taxonomy(). L’introduction du codex pour cette fonction indique que :
Cette fonction ajoute ou remplace une taxonomie. Elle a besoin d’un nom, du nom de l’objet auquel elle se rapporte et d’un ensemble de paramètres organisés en tableau.
Lorsqu’on s’intéresse à l’objet en question, le codex précise :
L’objet peut être un Post type natif ou tout Custom Post Type susceptible d’être créé
Mon problème, si j’arrête là mon exploration, est qu’étant donné que l’objet Groupe de BuddyPress n’est pas un Custom Post Type, il ne peut pas bénéficier d’une Custom Taxonomy. Je poursuis néanmoins car obstiné!
Il y a un peu moins d’un an, l’excellent Andrew Nacin a publié cet article très prometteur sur le « make ». Il précise à la fin « les taxonomies natives permettent de mettre en relation des posts (donc des post types) avec des termes, mais elles peuvent être manipulées pour mettre en relation des utilisateurs avec des termes (elles permettent déjà de mettre en relation des liens avec des termes, encore un autre type d’objet) ». Enfin, il conclut sur l’étude potentielle d’un mécanisme qui serait plus générique et qui permettrait de gérer tout type de relation.
Alors, je plonge dans le code source de WordPress et lance une recherche multifichiers sur « register_taxonomy » puis sur « register_post_type » et constate qu’effectivement, l’objet « link » utilise une taxonomie sans pour autant créer de Post Type. Voilà qui me motive à poursuivre mon expérimentation et me décide, ce samedi, à créér un plugin pour tester tout ça. J’ai terminé hier soir et point intéressant.. à première vue : it works! 🙂
On peut se demander si ma manipulation (pour reprendre un des termes que j’ai mis en gras dans les propos d’Andrew) ne représente pas un risque pour « l’équilibre » de son instance WordPress. J’ai envie de répondre pas plus que ce qui existe actuellement dans le « core » pour la gestion de l’objet « link » (tout en vous invitant à tester le plugin avec prudence 😉 ).
En tout cas, ce qui est certain, c’est qu’en utilisant les fonctions relatives aux taxonomies, on gagne énormément de temps dans la conception et on profite d’un mécanisme qui a fait ses preuves pour les post types. Ci-dessus, l’interface d’administration des tags a nécessité une vingtaine de lignes de code, ci-dessous, le widget de nuage de tags de groupes a nécessité une vingtaine de caractères!!
Avec ce plugin activé sur un WordPress 3.9.1 + BuddyPress 2.0.1, vous pourrez bénéficier d’une fonctionnalité de tagging des groupes. Seuls les super administrateurs seront en mesure de définir les tags, les administrateurs de groupe pourront choisir ceux sur lesquels ils souhaitent classer leur groupe. Enfin, si vous trouvez l’idée intéressante, je vous invite à tester ce plugin en prenant toutes les précautions d’usage (du type ne pas l’utiliser sur un site en production). De mon côté je vais le tester sur mon prototype de communauté 😉
25 réponses à “Expérimental: une taxonomie WordPress pour « tagger » les Groupes BuddyPress”
Thank you for this plugin. Works perfectly for the latest version of Buddypress and WordPress. My question is, how do we go about extending bp_groups_tag filter to the (Buddypress) Groups widget (the one that shows most Active, Newest, Popular groups), so that it only shows groups in specific tag(s)?
Thanks for your feedback. I agree it’s quite complex to achieve what you’re trying to do the way the plugin is built. I’ll see what i can do to make this easier.
Very solid plugin. It does exactly what I was hoping. Any plans to make this a production plugin?
Hi Thanks for your feedback Ryan. I don’t think so. With member types BuddyPress introduced some taxonomy functions and i think the feature that brings this plugin will be in core in a few releases from now. Once there, it will be even more robust 🙂
Hi imath, this is the plugin I was looking for but there seems to be a conflict with other plugins using tags. For me this is BP Docs and Events Manager. I use WP 4.1 with BP 2.2.1
It’s weird… Tags I associated with a new group lead to a page where parts of the BP Docs and parts of the Events Manager page appear (screenshot: http://ikmeaa.org/wp-content/uploads/bp-groups-taxo-master_bug.png)
When I first deactivate Events Manager, the parts from Events Manager disappear from the page. When I deactivate BP Docs, your plugin is working correctly. When I deactivate BP Docs first your plugin works fine, too. So I guess it’s BP Docs which is the conflicting plugin.
In oredr to exclude some issues, I tried to delete all the doc tags and disabled BP Docs for the new group. No effect!
I found the conflict! It were the tags of the previously installed BP group tags plugin. They had same names like the BP group taxo tags and were still stored in the xyz_bp_groups_groupmeta database table. After deleting them the plugin works perfect. Sorry for the confusion and thanks for this plugin. Sunny regards from Germany – Boris
Hi Boris,
Many thanks to you for your work on this. I’m sure it will be helpful for people having the same issue 😉
Hi imath,
I’m sorry that I have to inform you that the problem still exists in special cases and it is really the BP Docs plugin which causes this behavior (https://wordpress.org/plugins/buddypress-docs/)
When I create a group and do not enable BP Docs for the group your taxo works fine. Enabling Docs after the group is created works.
When I create a group and enable Docs the taxo associated to the goup does not work anymore. The others do. Disabling and enabling Docs after the group creation has no effect.
The weired thing is that everything is fine when I create a group with Docs enabled from a taxo-page.
Further there is a conflict with the groups widget. On a taxo-page it shows the error message « There are no groups to display. »
Regards,
Boris
Thanks Boris, the widget thing is kind of normal as the groups loop is the same, on the taxo page it should filter the ones having the current taxo. About BP Docs, sorry to read about This conflict 🙁
Yes, it’s a kind of weird. It works now again as it should and I can not figure out what I make different to do so.
Maybe you upgraded to WordPress 4.2.1 and now terms are splitted 🙂
Salut,
je suis en ce moment à la recherche d’un moyen de pouvoir classer mes groupes et je viens de tomber sur ta page.
En détournant ton plugin je devrai pouvoir arriver à mes faims, mais j’ai déjà détourné trop de trucs sur mon site et ça va commencer à devenir le bordel…et puis je bidouille plus que je ne code, c’est donc je pense au dessus de mes compétences^^
Ce que j’aimerai faire c’est avoir la possibilité de pouvoir afficher les groupes qui ont un certain tag (ou n’importe quoi d’autre, c’est juste pour pouvoir les classer, je ne souhaite pas que ça soit visible sur le site comme un tag) sur une page et ensuite les groupes avec un autre tag sur une autre page. Je souhaiterai trouver un moyen de rendre visible les groupes (public) qu’à un certain type d’utilisateur, suivant son pays par exemple.
Est ce que tu pense que ce genre de chose serai possible en partant de ton plugin? ou via un autre plugin qui aurait croisé ta route par exemple?
Merci 🙂
Hello, ce plugin permet de créer des tags pour classer les groupes. Dans la liste des groupes ceux qui sont taggés présenteront un lien sous leur description pour afficher les groupes qui sont eux aussi taggés selon le même terme. J’imagine que ça peut répondre à une partie de ton besoin. Il existe au moins un autre plugin que je cite dans cet article je crois.
Merci pour la réponse. 🙂
Mon problème c’est que les tags ne sont pas reconnu par mon thème, il faudrait je pense que je modifie le code pour ça. Et je souhaiterai que ses tags soient invisibles, qu’ils ne servent qu’a classer les groupes. J’ai peur de devoir mettre les mains dans le code, chose que j’aurai bien évité.
I love this plugin iMath! I was wondering if there is any code I can add to restrict only 1 tag during group creation. I’m having users spam all the tags and selecting every option instead of groups that are relevant.
Bonjour Imath, bravo pour cet excellent plugin qui apporte la synthèse nécessaire à un bon usage des groupes. Tu précisais sur un autre article que le Member_Type apporterai nativement des options pour gérer cette taxonomie, alors j’aimerais savoir si tu prévois créer un version de ce plugin sur cette base là, ce qui rendrait plus sur son utilisation sur un site en prod’. Merci
La fonctionnalité des « member types » a effectivement introduit dans le core de BuddyPress un certain nombre de fonctions liées à l’utilisation d’une taxonomie pour qualifier un objet BuddyPress.
S’agissant des Groupes, il y a un ticket sur notre Trac ainsi que des patches, il est donc fort probable qu’un jour le core de BuddyPress s’intéresse aux taxonomies pour les Groupes.
Par conséquent, je ne prévois pas de faire évoluer ce plugin qui reste selon moi une rustine.
Très bien , j’ai vraiment hâte de découvrir les prochaines possibilités de Buddypress 🙂 D’autre part ,dans le cadre de cette rustine je me demandais comment mettre des boutons radio au lieu des check-box pour la sélection des tags ?
comme cela: https://github.com/imath/bp-groups-taxo/issues/6
God Bless You.. Merci imath et à bientot sur d’autres sujets tout aussi excitants 🙂
Thanks for creating this plugin! Is there a way to get a list of all the user/member IDs for that Group, including the user ID of the creator of the Group by tag?
For example, I would like that data to be output as JSON so that I can apply Javascript to produce specific content on a regular WordPress page.
Thanks for your feedback. Getting user ids for a Group Tag? i guess you’d need to get the group ids for the tag and then get group members for this list of group ids. Should be possible yes 🙂
Bonjour,
Merci d’avance pour le plugin qui marche nickel.
Par contre si je souhaite faire une requete sur les groups par taxo…
Comment fait-on ? Une idée ?
Merci
Faudrait que je teste, mais je pense qu’en définissant
buddypress()->groups->tag->term = 'tag';juste avant de lancer un loop sur les groupes pourrait fonctionner..Autrement la version 2.6 ce BuddyPress va introduire les Group types, tu devrais commencer à regarder cette fonctionnalité 😉
Je confirme qu’il est possible de faire comme ceci: https://gist.github.com/imath/039456f31f48596ec0e41efa98b5946a