wordpress multisite : gestion des utilisateurs

par Anne-Laure DELPECH | 30 Sep 2016 | Archives

Vous avez crée votre réseau de site WordPress avec la fonctionnalité multisites. Jusqu’à présent, il était possible d’avoir le même identifiant (même adresse mail) en tant qu’utilisateur de différents sites. Mais sur un multisite, si j’utilise le même identifiant pour créer des contenus dans plusieurs sites, ils auront tous les mêmes renseignements biographiques.

Pourquoi éviter d’avoir un seul identifiant ?

Pour des renseignements biographiques ciblés sur les thématiques du site

Par exemple sur ce site, knowledge.parcours-performance.com, j’utilise la même adresse mail comme administrateur que pour mon site parcours-performance.com et je n’y ai pas mis les mêmes renseignements biographiques. C’est logique puisque mon parcours « maker » n’intéresse pas les lecteurs de l’autre site et mon parcours « organisation et lean management » ne vous intéresse pas. En multisite, si je veux avoir des renseignements biographiques différents pour le même auteur, il faut des identifiants différents (donc des adresses mail différentes).

Car WordPress est fait comme ça…

WordPress gère les utilisateurs pour l’ensemble des sites du réseau avec un identifiant unique et une adresse mail unique. On ne peut donc pas se créer plusieurs fois…

Pour des raisons de sécurité

Les identifiants et mots de passe des super administrateurs donnent l’accès à toute la machinerie du site. Ils doivent donc être protégés, et jamais enregistrés sur l’ordinateur. Imaginez ce qui se passerait si votre nièce ou votre fils allait modifier des éléments du tableau de bord du réseau !

Pour éviter les erreurs

https://c5.staticflickr.com/9/8085/8562448300_2a5c7b1e59.jpg

Une erreur sur un site isolé est déjà très embêtante, alors sur un ensemble de sites…

Lorsqu’on met notre « casquette » d’éditeur, on peut rédiger et publier des contenus.

Lorsqu’on met notre « casquette » d’administrateur d’un site, on peut modifier la structure du site (avec quelques limites).

Et lorsqu’on est enregistré en tant que super administrateur, on a tous les droits : on peut ajouter des extensions sans même s’être préoccupé de leurs compatibilité multisite ou de leur sécurité, on peut faire des mises à jour sans avoir au préalable vérifié les impacts sur un site de développement, …, on peut casser plusieurs sites d’un clic !

Il est donc préférable d’avoir l’esprit tranquille lorsqu’on est éditeur : on ne peut rien faire de très grave. Lorsqu’on est administrateur, on doit déjà réfléchir à deux fois aux conséquences d’un clic. Et lorsqu’on est super administrateur, on doit être ultra-vigilant, presque paranoïaque, et systématiquement tester nos choix avant de les mettre en oeuvre.

Les bonnes pratiques adoptées sur mes sites multisites

Principe n°1 : une même personne peut avoir plusieurs rôles mais elle a un identifiant par rôle (et donc une adresse mail différente par rôle).

Principe n°2 : sur deux sites différents d’un même multisite, un même auteur (ou éditeur) a un identifiant différent et donc une adresse mail différente. Il/elle peut ainsi avoir des renseignements biographiques différents et choisir des couleurs de tableau de bord différentes pour limiter les erreurs.

Principe n°3 : une personne qui peut avoir accès à l’ensemble du multisite est super administrateur. Elle peut avoir les fonctions d’administrateur dans n’importe quel site sans changer d’identifiant. A l’inverse, une personne qui peut être administrateur d’un ou plusieurs sites ne dispose pas des droits de super-administrateur.

Nota : pour éviter de mémoriser un nombre délirant d’identifiants et mots de passe, il est possible d’utiliser une extension comme « user switching« , qui permet de changer de rôle simplement. On peut aussi explorer des gestionnaires de mot de passe comme LastPass ou KeePass, voire Dashlane.

Créer les bons utilisateurs aux bons endroits dans un multisite

Pour l’instant, je vais considérer que nous avons assez d’adresses mail distinctes, et que nous en recevons tous les messages au fur et à mesure. Dans un article à venir, j’en parlerai plus précisément.

Le contexte :

Je suis dans un multisite dont le site principal contient une centaine d’articles écrits par moi lorsque je n’étais que « administrateur » de ce site solo. Maintenant, ce même identifiant est devenu « super administrateur ».

D’autres sites sont venus s’ajouter dans le multisite et il faut que je reste l’auteure de ses contenus, mais avec un autre profil pour ne pas être obligée d’avoir des renseignements biographiques uniques.

Ce que je vais faire :

Je vais définir des adresses différentes pour tous les rôles suivants.

Pour le site principal (PRINCIPAL.com) :

pour les « sous » sites du réseau « SOUS.PRINCIPAL.com, on peut être administrateur avec l’identifiant du site principal mais si on produit des contenus on le fera sous l’identifiant de l’éditeur spécifique à ce sous site.

Mon site de test est composé de trois sites :

1. le site principal, potentiel-web.com
2. un site secondaire, test1.potentiel-web.com
3. un site secondaire, test1.parcours-performance.com

Il va donc falloir que je crée les utilisateurs avec des mails ressemblant à ce qui suit :

Pour potentiel-web.com :

Pour test1.potentiel-web.com

Pour test1.parcours-performance.com, j’utilise le nom de domaine principal, pas celui du site principal.

Comment je le fais :

Comme les deux sites ajoutés dans le réseau sont des sites tous neufs, il n’y aucun contenu dedans. Je n’ai donc pas à me préoccuper de transférer les contenus à un nouvel utilisateur. Mais pour le site principal, il faut que je puisse transférer le contenu du super administrateur actuel à un simple éditeur.

créer les utilisateurs dans l’administration du réseau

Pour tous les sites, principal ou pas, je vais dans « Mes sites » > « Admin du réseau » > « Utilisateurs » et j’y crée un à un les 7 comptes indiqués ci-dessous avec le bouton « ajouter ».

Lorsque j’ai créé les trois premiers, la liste de mes utilisateurs devient comme ci-dessous. Pour des raisons évidentes de sécurité, ce sont des identifiants que je n’utiliserai pas, pas plus que les adresses mails indiquées. Et il faut noter que je suis connectée en tant que super administrateur avec un identifiant qui n’est pas affiché dans cette liste mais qui le sera pour vous.

Pour l’instant ces utilisateurs n’ont aucun rôle (et ils n’en auront jamais puisque les adresses mail n’existent pas, je ne pourrai donc jamais générer un mot de passe…).

Pour le super administrateur, je clique sur modifier puis je coche la case « Donner les privilèges de super-admin à cet utilisateur pour le réseau. ». superadminwhatever est maintenant devenu super administrateur !

Donner des rôles aux utilisateurs dans les différents sites

Les 2 autres utilisateurs ci-dessus doivent avoir des rôles dans le site primaire, potentiel-web.com.

Dans « Mes sites » > « Admin du réseau » > « Sites », j’ai la liste des sites du réseau. Lorsque je survole le nom d’un site, je vois apparaître des liens.

Je clique sur « modifier » en dessous du nom du site principal. Je vois alors un écran avec 4 onglets. Je vais dans « utilisateurs ».

Sous la liste des utilisateurs déjà affectés, il y a la possibilité d’ajouter un utilisateur existant. Je tape les premiers caractères d’un utilisateur et WordPress me propose un utilisateur. Je lui donne le rôle correspondant. Je fais ça pour l’éditeur et l’administrateur de chaque site.

transférer les contenus du super administrateur actuel à l’éditeur

Il faut avant avoir rempli le prénom et le nom de l’utilisateur, relié le compte à une photo (gravatar), et rempli les renseignements biographiques du compte éditeur.

Lorsqu’on supprime le super administrateur (il faut s’être reconnecté au préalable sous l’identifiant du nouveau superadministrateur), WordPress demande à qui on veut attribuer le contenu de cet utilisateur. On l’attribue à editeurwhatever et le tour est joué !

Et maintenant ?

Il faudra apprendre à gérer de nombreux identifiants et mots de passe…

Un site « multisite » WordPress sur OVH mutualisé

par Anne-Laure DELPECH | 13 Sep 2016 | Archives

WordPress est habituellement utilisé pour un seul site. C’est plus simple mais ça présente aussi des inconvénients :

• si vous un hébergement mutualisé (Pro OVH par exemple) avec seulement 4 bases de données, vous ne pouvez pas créer plus de 4 sites.
• Si vous gérez 4 sites, il faudra faire autant de fois les installations de WordPress, les mises à jour de WordPress et des extensions.

J’expérimente ici la création d’un site multisite à partir d’un nom de domaine « potentiel-web.com » sur un hébergement Pro mutualisé d’OVH. Ce site a déjà été créé, avec un certificat SSL « Let’s Encrypt » (voir l’article WordPress avec un SSL Let’s encrypt sur OVH mutualisé). Nous allons maintenant le rendre multisites. 

Qu’est-ce que WordPress multisite ?

Un réseau WordPress multisite, c’est un ensemble de sites internet distincts qui partagent une seule installation de WordPress. Le site WordPress.org, qui est composé de millions de sites en est un exemple. Chaque site du réseau est en fait un site virtuel, qui dispose cependant de son propre répertoire « upload » pour les médias et de ses propres tables dans la base de données.

Les extensions et thèmes sont installées au niveau de la tête de réseau mais chaque site peut les activer ou les désactiver.

Un réseau de sites peut fonctionner selon deux principes distincts :

• en « sous-domaines » : les sites auront des url du type site1.domaine.com, site2.domaine.com ;
• en « sous-répertoires » : les sites auront des url du type domaine.com/site1, domaine.com/site2.

A quoi ça sert ?

Un seul individu (ou entreprise) peut avoir plusieurs sites ou blogs. Ca devient vite compliqué de les gérer chacun individuellement, de les mettre à jour, d’ajouter la même extension dans chacun. On peut donc utiliser la fonctionnalité multi-sites de WordPress pour n’avoir qu’une seule installation de WordPress, des extensions et des thèmes pour plusieurs sites distincts.

Un développeur, ou une agence web, pourra aussi avoir un réseau de sites de clients installés et administrés d’un seul endroit. Les clients peuvent avoir un accès administrateur à leur propre site s’ils le souhaitent. L’avantage est qu’ils ne pourront pas ajouter des thèmes ou des extensions.

On peut également avoir un réseau dans lequel des gens peuvent ajouter leur propre site, gratuitement ou moyennant paiement.

Dans tous les cas, une extension spécialisée permet le « domain mapping » et autorise l’utilisation de noms de domaines différents pour chaque site du réseau.

étape 1 : régler WordPress

C’est WordPress qui gérera les sous-domaines, pas notre espace client OVH. Je ne crée donc pas de sous-domaine sur OVH.

Pour cette étape, je m’inspire des tutoriels suivants :

• un article de Grégoire Noyelle, « WordPress :: Créer un réseau de sites » ;
• « The Ultimate Guide to WordPress Multisite« , sur wpmudev ;
• « Configurez simplement un multisite WordPress sur un mutualisé OVH« , sur lumieredelune.com.
• Create a network, sur le codex WordPress (la version française n’est pas très bonne, comme souvent) ;
• « before you create a network« , également sur le codex WordPress.

Activation du réseau: dans wp-config.php

Ajouter les deux lignes suivantes dans wp-config.php , juste avant la ligne « /* C’est tout, ne touchez pas à ce qui suit ! Bon blogging ! */ » :

/* Multisite */
define('WP_ALLOW_MULTISITE', true);

Créer le réseau, dans WordPress

Dans le menu « outils » du tableau de bord WordPress, il y a maintenant un menu « création du réseau ». Les extensions éventuellement présentes doivent avoir été désactivées avant.

Il faut (1) choisir entre le mode « sous-domaines » et le mode « sous-répertoires ». J’ai choisi « sous-domaines » car j’ai le sentiment que c’est mieux adapté, mais je ne suis pas certaine d’avoir tout compris. J’ai lu que c’était compliqué de transformer un site existant en mode multisite avec sous-répertoires car les anciennes url ne vont plus fonctionner correctement. Comme ces essai est un préalable à la transformation d’un site existant, il m’a semblé plus simple d’essayer tout de suite en sous-domaines.

Il faut également indiquer (2) le titre du réseau et (3) l’adresse email de l’administrateur du réseau (le super administrateur).

Ensuite, on clique sur « installer ». Pour cet essai, je pars d’un site vide, mais évidemment, si on part d’un site existant, il faut impérativement sauvegarder la base de données et les fichiers avant de réaliser cette modification.

Après avoir cliqué sur « installer », nous arrivons à une page assez effrayante…

Dans l’écran qui s’affiche, on voit trois éléments :

1. Une alerte « Attention ! L’enregistrement DNS générique (joker) peut ne pas être configuré correctement ! ». Pour l’instant, nous ne nous en préoccupons pas.
2. du code qu’il faudra ajouter à  wp-config.php
3. du code qu’il faudra ajouter au fichier .htaccess

Modifier wp-config.php

Je copie puis colle le contenu indiqué dans l’écran WordPress dans mon fichier  wp-config.php , sous la ligne contenant define(‘WP_ALLOW_MULTISITE’, true);

Modifier le fichier .htaccess

Le nouveau contenu de ce fichier est maintenant :

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]

# add a trailing slash to /wp-admin
RewriteRule ^wp-admin$ wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^(wp-(content|admin|includes).*) $1 [L]
RewriteRule ^(.*\.php)$ $1 [L]
RewriteRule . index.php [L]
</IfModule>

# END WordPress

Se reconnecter

Une fois les modifications faites, j’ai cliqué sur « reconnecter » en bas de la page WordPress qui contenait les instructions.

Mon tableau de bord WordPress contient maintenant un nouveau menu « mes sites ».

Créer un nouveau site dans le réseau

Nous allons créer un sous-domaine test1.potentiel-web.com.

Dans le tableau de bord WordPress

Lorsque je me connecte à potentiel-web.com/wp-admin, j’ai une interface WordPress qui paraît identique à celle d’un site unique classique. Mais il y a des différences :

• sous le menu « tableau de bord », il y a maintenant un menu « mes sites », comme vu précédemment.
• Mais surtout, maintenant si je place ma souris tout en haut sur le titre du site, j’ai un sous-menu « admin du réseau » qui apparaît.

Si je vais dans le sous-menu « Sites », je peux créer, supprimer, modifier des sites du réseau, comme si c’était des articles ou des pages !

Je crée donc le site test1.potentiel-web.com :

Après avoir cliqué sur « ajouter un site », ce nouveau site apparaît dans la liste de mes sites. J’ai reçu aussi plusieurs mail :

• des mails à mon adresse donnée lorsque j’ai créé le multisite, mon adresse de « super admin » !
• des mails à l’adresse que je viens de donner comme administrateur de test1.potentiel-web.com. Ces mails m’informent de la création du site et indiquent où aller pour configurer mon mot de passe.

Mais si je met « test1.potentiel-web.com » dans un navigateur , j’obtiens une page d’erreur « Impossible de trouver l’adresse DNS du serveur test1.potentiel-web.com ». Il faut que je crée le nom de domaine dans OVH. 

Création du sous-domaine dans l’espace client OVH

dans l’espace client d’OVH. Je clique sur l’hébergement auquel est rattaché mon site multisite puis sur l’onglet « multisite ». Ensuite je clique sur le bouton « ajouter un domaine ou un sous-domaine ».

Dans l’étape 2, il n’y a aucune raison de créer également le sous-domaine avec le www. Je ne le fais donc pas.

Le répertoire cible doit être celui du domaine principal du réseau de sites (multi-test pour moi – la copie d’écran ci-dessous indique www mais c’est multi-test qu’il faut lire, le répertoire où est installé potentiel-web.com).

Je choisis l’option SSL puisque je veux que tous mes sites soient encryptés.

Je choisis log séparé car c’est plus clair.

OVH affiche « La modification du ou des domaines associé(s) à votre hébergement mutualisé est en cours … » et quelques minutes plus tard, il devient possible d’accéder à http://test1.potentiel-web.com. Il n’est toujours pas possible d’accéder à  https://test1.potentiel-web.com (la version encryptée) car je n’ai pas encore régénéré le certificat ssl.

Accéder au nouveau site et le modifier

Si je me connecte au nouveau site test1 (j’ai été créée comme administrateur en tant que « test1 »), je perds ma connexion de super administrateur, ce qui est normal puisque j’ai indiqué un autre email que celui du super administrateur comme administrateur du site test1…

En tant qu’administrateur de test1.potentiel-web.com, je peux faire tout ce que peux faire un administrateur d’un site unique, sauf installer des thèmes ou des extensions. Ces installations, le super administrateur est seul habilité à les réaliser.

Modifier les utilisateurs en tant que super administrateur

Dans le menu « admin du réseau », sous-menu « Sites », je peux modifier les sites du réseau.

Si je clique sur « modifier » pour le site test1, j’ai accès à 4 onglets, dont l’onglet utilisateurs. Je peux ajouter un utilisateur existant ou un nouvel utilisateur.

J’y ajoute l’utilisateur que je suis en tant que super administrateur. Maintenant avec un seul utilisateur, je peux aussi bien agir dans le site test1, que dans le site principal ou administrer le réseau de site.

Installer des thèmes et extensions en tant que super administrateur

En tant que super administrateur, je peux installer un nouveau thème ou une nouvelle extension.

Installer un nouveau thème

soit avec « ajouter », dans le menu « admin du réseau » > « thèmes », pour un thème présent dans les thèmes de wordpress.org ou par ajout de fichiers dans le répertoire /racine/wp-content/themes  comme dans un site unique.

Activation d’un nouveau thème

Dans la liste des thèmes, chacun peut être activé ou désactivé pour le réseau dans le menu « admin du réseau » > « thèmes ».

Si je souhaite qu’un thème soit disponible pour tous les sites du réseau : je clique sur « activer pour le réseau ».

Si au contraire je ne souhaite mettre ce thème à disposition que de certains site, je vais dans le menu « admin du réseau » > « sites » et, pour chaque site, je clique sur modifier et je vais dans l’onglet thème.

Ainsi j’ai installé le thème stargazer et je l’ai activé pour tous les sites. Ensuite j’ai installé un thème enfant de stargazer (par transfert de fichiers) et je l’ai activé dans le site « test1 » seulement.

Installer une extension

dans le menu « admin du réseau » > « extensions », je peux ajouter une extension avec le bouton « ajouter » pour pour une extension présente dans les extensions de wordpress.org ou par ajout de fichiers dans le répertoire /racine/wp-content/plugins  comme dans un site unique.

Activation d’une extension

Attention, une extension qui ajoute des tables dans WordPress doit être compatible multisite pour fonctionner correctement (voir l’article Make WordPress Plugin compatible with Multisite). Si une extension n’est pas compatible multisite, on pourra l’activer dans chaque site du réseau mais pas pour tout le réseau.

J’installe l’extension « Yoast SEO » qui dit être compatible multisites et « HMS Testimonials » qui est ancienne et n’indique pas de compatibilité multisite, tout en créant des tables.

Lorsque j’active ces deux extensions sur le réseau, dans le menu « admin du réseau » > « extensions », je n’ai aucun message d’erreur.

Et lorsque je vais voir le contenu de la base de données du réseau de site, elle contient autant de tables que de sites, tous avec un préfixe du genre prefixe_nom_table : prefixe tout court pour le site principal, prefixe_1 pour le premier site ajouté, etc… Et HMS Testimonials a ajouté plusieurs tables pour chaque site. Il n’y a donc pas de souci.

Spécificités du SSL (https)

Comme le site principal est crypté, les liens vers les autres sites sont en https. Le certificat SSL doit donc les inclure : J’ai ajouté un deuxième site, test2.potentiel-web.com, j’ai attendu deux heures comme indiqué par OVH puis j’ai régénéré le certificat ssl sur mon espace client OVH.

La régénération est assez longue mais pendant ce temps les sites qui étaient déjà encryptés conservent leurs certificats SSL et fonctionnent donc correctement.

Au bout d’une dizaine de minutes le certificat est régénéré. Au départ, j’ai un problème car le site https://test1.potentiel-web.com est annoncé comme non sécurisé…

La solution : retourner dans le menu « admin du réseau » > « sites » et modifier l’adresse du site de destination. C’était http://test1.potentiel-web.com. J’ajoute un s à la fin de http, et ça y est c’est bon !

Il faut également effectuer des redirections lorsqu’une url est appelée sans rien devant ou en http. Mais on ne doit pas rediriger une url contenant à la fin wp-admin.*, wp-config.* ou wp-includes.*

Donc on modifie .htacess pour que (merci aux auteurs des réponses à cette question sur Stackoverflow) :

• quand le port est 80 (si la connexion était sécurisée elle utiliserait le port 443. Quand elle utilise le port 80, elle est en http)
• ET l’url appelée (%{REQUEST_URI} ) n’est ni wp-content, ni wp-admin, ni wp-includes suivi de n’importe quoi,
• ALORS on redirige vers la version https de l’url.

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]

# add a trailing slash to /wp-admin
RewriteRule ^wp-admin$ wp-admin/ [R=301,L]

# direct everything to https
RewriteCond %{SERVER_PORT} 80
RewriteCond %{REQUEST_URI} !(wp-(content|admin|includes).*)$ 
RewriteRule ^(.*)$ https://%{SERVER_NAME}/$1 [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^(wp-(content|admin|includes).*) $1 [L]
RewriteRule ^(.*\.php)$ $1 [L]
RewriteRule . index.php [L]
</IfModule>

# END WordPress

Noter qu’il faut parfois vider le cache du navigateur pour que la réécriture des url sans http se fasse correctement… J’ai Chrome réglé pour conserver les historiques et Firefox qui ne les conserve pas. Je teste donc dans Firefox puis quand ça fonctionne, j’efface les données de navigation de moins d’une heure dans chrome, en ne sélectionnant que « cookies et autres données » et « images en fichiers en cache ».

et dans wp-config.php , il est préférable d’ajouter une ligne qui force l’usage du SSL pour l’administration :

/* HTTPS only for admin access */
define( 'FORCE_SSL_ADMIN', true );

Et maintenant ?

J’ai donc réussi à créer un réseau de sites avec la fonctionnalité multi sites de WordPress. Ca me semble pratique. Je vais maintenant devoir migrer mes sites existants sur un réseau, apprendre à bien utiliser les réseaux multisite et surtout à les sauvegarder et restaurer si nécessaire…

Je prévois de faire les articles suivants pour compléter mon apprentissage des réseaux multisites WordPress :

• Tester l’ajout de sites dont les noms ne sont pas des sous-domaines du site principal (c’est fait, dans « Associer un nom de domaine à un site d’un réseau WordPress (multisite)« ).
• Transformer un site existant en un site multisite WordPress et y ajouter deux nouveaux sites (créés pour l’occasion) à partir d’un site « standard » (utilisation de l’extension Multisite Cloner) ;
• Explorer les possibilités de sauvegarde et restauration en multisite. J’envisage d’arrêter mon compte ManageWP : ManageWP est compatible avec WordPress multisite comme indiqué dans l’article « WordPress Multisite and ManageWP« , mais « cloning from / to a multisite installation is not supported!« . Peut-être que l’extension (premium) SNAPSHOT PRO de WPmudev le remplacera avantageusement. Voir aussi Moving WordPress Multisite, sur le codex WordPress
• migrer un site solo existant vers un multisite (et inversement)
  • Moving WordPress: Moving a Site Into a Multisite Network
  • Migrating Multiple Blogs into WordPress Multisite
  • Move an Existing Blog into WordPress Multi-Site
  • et pour migrer un site issu d’un réseau vers un site unique, Moving WordPress: Moving a Site Out of a Multisite Network et Best way to migrate a single site from WP network?

Ces sujets feront l’objet de plusieurs articles pour cette série WordPress Multisite sur OVH mutualisé.