imath

Pour inaugurer une série d’articles que je souhaite dédier à ma configuration de WordPress préférée , je vous propose de redécouvrir l’ancêtre du Multisite :

Pourquoi ?

Si je demande à la plupart d’entre vous de définir le Multisite, il y a de fortes chances que vous me répondiez « ben c’est pour créer un réseau de sites WordPress ». Bien Evidemment ! Toutefois je crains que ce raccourci disqualifie en quelque sorte une utilisation plus fréquente de cette configuration pour tous ceux qui n’ont besoin que d’un seul site 🙄.

Dernièrement j’ai lu cet intéressant article de ipstenu dans lequel, de manière un peu autoritaire, elle conseille de ne pas utiliser cette configuration. J’ai compris de son propos qu’il convenait de n’utiliser le Multisite que si vous envisagez de construire votre propre WordPress.com ou plus modestement si les sites que vous prévoyez de créer sont très hétérogènes les uns des autres. Autrement, elle indique que l’utilisation des « custom post types » est bien souvent la meilleure des alternatives à la plupart des besoins.

MultiSite, either by intention or effect, works best when you think of it as running your very own version of WordPress.com.  You have a network of sites that are disconnected from each other, data wise, but share the same available user base.

Alors moi qui n’hésite pas à l’utiliser pour un seul site, c’est à dire sans jamais créer d’autres sites que le principal, suis-je complètement à côté de la plaque ? Pour y voir plus clair, et essayer de trouver le premier critère qui, selon moi, doit nous guider dans le choix de notre configuration WordPress, je vous propose un petit retour aux sources.

WordPress µ : 10/10/2006 – 17/06/2010.

Le 10 octobre 2006, la version 1.0 de WordPress µ est publiée. Il s’agit, à l’époque, d’un projet bien séparé de WordPress qui est effectivement à la base du service WordPress.com. J’attire votre attention sur ce qui se cache derrière ce « µ » ou « mu ». Lorsque nous lisons cette page du codex nous apprenons que cela correspond à « multi-user ». WordPress µ se définit donc comme la version multi-utilisateurs de WordPress grâce à laquelle de nouveaux utilisateurs peuvent s’inscrire et obtenir un blog. Un peu plus de 4 ans plus tard sa version 2.9.2 sera la dernière avant l’intégration des fonctionnalités du µ au sein du projet WordPress à l’occasion de la sortie de sa version 3.0 baptisée Thelonious le 17 juin 2010. J’insiste sur ce point : depuis lors, quoiqu’il arrive votre WordPress contient les fonctionnalités du Multisite, elles sont juste inactives.

Comme l’illustre la capture d’écran, cette semaine je me suis amusé avec cette version collector de µ. Et une chose m’a frappée : à l’époque le blog principal est imaginé comme un portail pour accueillir de nouveaux membres et leur permettre d’éventuellement créer leur blog (bien entendu !).

L’utilisation des articles de ce blog permet d’alimenter des actualités (« Site News« ) et une rubrique liste les 40 blogs ayant eu une activité récemment (« Updated blogs« ). Cette dernière rubrique m’a fait sourire « un répertoire des blogs du réseau a jadis existé! Diantre, et moi qui croyait que BuddyPress était un des tous premiers à proposer ce type de fonctionnalité ! ». Par ailleurs, j’ai moi même exploré ce terrain avec ClusterPress en y rajoutant des « fiches de découverte » pour chacun des sites.

Mais revenons à nos moutons ! Avez-vous remarqué ? Sur la capture ci-dessus, le formulaire d’inscription s’affiche dans le thème et n’est pas une action spécifique de l’écran wp-login.php comme c’est le cas dans le WordPress classique.

Autre différence primordiale, qui me fait dire que le WordPress classique n’est pas fait pour gérer des inscriptions mais autorise plutôt des visiteurs à devenir des utilisateurs, lorsqu’on remplit ce formulaire nous n’intégrons pas la table des utilisateurs de WordPress (wp_users), nous entrons dans une table intermédiaire celles des inscriptions (wp_signups). Et ce n’est que lorsque l’utilisateur activera son compte en cliquant le lien reçu par email qu’il intègrera la table des utilisateurs.

Même, si à mon avis, l’insertion de ce formulaire d’inscription et de celui d’activation est faite un peu « brutalement » au sein du thème (je reviendrai sur ce point dans un prochain article), avec µ (et donc le Multisite de nos jours) nous sommes équipés d’un vrai processus d’enregistrement de comptes contrôlable depuis les options de la zone de « super » administration du « backend ».

4 choix sont offerts : portes grandes ouvertes pour l’accueil de nouveaux blogs et comptes, portes entrouvertes aux nouveaux comptes, portes fermées ou encore les résidents existants peuvent créer de nouveaux blogs.

D’autres options complètent ce dispositif et notamment l’exclusivité si importante de µ (et donc du Multisite) : la potentielle restriction de l’inscription aux domaines d’email de votre choix. Lorsqu’on héberge un intranet sur internet, cette option est très intéressante pour s’assurer que les nouveaux venus font bien partie du périmètre de l’organisation.

Autre exclusivité très importante lorsqu’on a besoin de gérer des utilisateurs, WordPress µ (et donc le Multisite) enrichit la modération de vos membres en ajoutant la possibilité de les neutraliser temporairement en les marquant comme « spam ». Dés lors, leurs comptes bien que toujours existants ne leur permettra plus de créer de nouveaux contenus sur le réseau de blog.

Ainsi, il me semble que le premier critère pour choisir la configuration de WordPress qui convient le mieux à notre projet est le besoin de permettre à des utilisateurS de rejoindre le site (ou le réseau de sites) et de bénéficier du meilleur cadre pour gérer ces membres. Mon point majeur est qu’il me semble complètement dommage d’activer des extensions pour remplir ces fonctions alors qu’elles sont déjà incluses dans votre WordPress simplement parce que notre contenu n’est pas suffisamment hétérogène pour qu’on le répartisse sur plusieurs sites.

Le riff de Django : 23 février 2011

La 3.0 de WordPress a globalement fait en sorte d’intégrer les fonctionnalités du µ dans un seul et même projet. C’est lors de la publication de la version 3.1 que le Multisite qu’on connait aujourd’hui s’est précisé.

La première évolution importante a consisté à équiper l’administration du réseau de sa propre interface. Il est vrai que l’héritage de µ la superposait au dessus de l’administration du site principal ce qui pouvait générer des confusions.

Autre « r »-évolution il n’est plus nécessaire qu’un utilisateur ait un rôle sur un des sites du réseau Multisite. En effet dans WordPress ou dans WordPress µ l’utilisateur a systématiquement un rôle. D’ailleurs pour m’en assurer, j’ai fait le test suivant sur µ : en tant qu’utilisateur je me suis inscrit et ai créé un blog. Le compte créé a eu un rôle sur le blog créé et aucun sur le blog principal. Ensuite en tant que « super » administrateur, j’ai supprimé le blog en question.

Tant que l’utilisateur ne se connecte pas, il n’est rattaché à aucun blog. Dés qu’il se connecte il est automatiquement affecté au blog principal en tant qu’abonné (ou tout autre rôle en fonction du réglage du rôle par défaut défini dans les options). J’imagine que la difficulté de l’époque était liée à la nécessité de maintenir une possibilité pour l’utilisateur de modifier son profil depuis une zone d’administration du blog auquel il est affecté.

La version 3.1 a introduit une interface d’administration spécifique pour les utilisateurs orphelins de rôle (et donc de site!) à partir de laquelle il sera toujours possible d’éditer les informations de profil. Se pose alors la question de l’intérêt du rôle d’abonné dans la mesure où un utilisateur sans rôle n’a pas, à ma connaissance, moins de possibilités qu’un abonné. Il faut savoir, toutefois, que l’administration d’un site (qu’il repose sur une configuration classique ou Multisite) ne listera que les utilisateurs ayant un rôle sur ce site. En revanche, depuis l’administration du réseau de sites, on retrouvera en permanence l’intégralité des comptes créés sur ce réseau.

Voici qui termine l’article inaugurant cette nouvelle série dédiée au Multisite. Si j’ai surtout parlé de la gestion des utilisateurs comme vous avez pu le constater c’est parce qu’il s’agit, au delà de toute considération de contenu, le premier élément différenciant qui peut faire pencher le choix entre une configuration classique et une configuration Multisite. Bien entendu, cela reste un avis très personnel, vous êtes absolument libre d’utiliser WordPress comme bon vous semble.

Par ailleurs, comme je n’en parle pas, si vous avez besoin d’activer la configuration Multisite : je vous recommande cet excellent tutoriel de Grégoire qui vous permettra j’en suis convaincu d’y arriver du premier coup 🙂

Enfin, j’attire votre attention sur le prochain podcast de Very French Trip qui sera précisément consacré au Multisite, au plaisir d’en discuter de vive voix avec vous le 2 février prochain.