Le fonctionnement multisite de WordPress est très pratique et simple mais je suis contrainte de scinder un multisite (heureusement encore peu fourni) car je transfère le site sur un VPS avec Plesk et il est pour l’instant impossible d’avoir plusieurs domaines distincts avec des certificats Let’s Encrypt distincts sur un seul hébergement Plesk…
Les spécificités du multisite
Si on veut sortir un site d’un multisite, il faut le « détricoter » :
Pour les fichiers, il faut remettre toutes les extensions du site principal dans le site devenu orphelin et il faut également lui transférer ses fichiers médias. C’est simple à faire.
Dans la base de données, c’est plus compliqué. Il y a des tables spécifiques au site à séparer mais certaines sont partagées entre tous les sites du multisite. C’est là que le détricotage est un peu fastidieux.
Trouver l’identifiant du site à sortir
Dans le tableau de bord du multisite, aller sur mes sites > Admin du Réseau > Sites.
Passer la souris sur le nom du site à déplacer (disons « subdomain.com »). Son url complète s’affiche en bas de la fenêtre, sous la forme https://domaine.comwp-admin/network/site-info.php?id=3. Ici l’identifiant est donc « 3 ». On en aura besoin pour la suite.
Sauvegarder le multisite
Sauvegarder les fichiers
Avec Filezilla : sauvegarder le répertoire /www/wp-content/uploads/sites/3 (3 est l’identifiant du site que l’on veut sortir).
Sauvegarder la base de données
Nota du 23/11/216 : pour des raisons que j’ignore, l’export via PHPMyAdmin provoque parfois une erreur : les index et auto-incrémentations ne sont pas transférés. Dans ce cas, il faut aller dans l’interface client de l’hébergement OVH original et demander une sauvegarde de la base de données (un dump) que l’on reçoit quelques minutes plus tard par mail. Cette sauvegarde s’importe ensuite sans souci dans la base Plesk.
Noter les informations du site
On a intérêt à bien noter (copies d’écran) les informations suivantes :
quel est le nom du thème (stargazer pour moi) et ses réglages ?
quelles sont les extensions utilisées et faisant l’objet d’un réglage spécifique ? Pour mon cas, Cookie Notice, Floating Social Bar
Dans l’installation de WordPress, copier /www/wp-content/uploads/sites/3 de l’ancien site vers /www/wp-content/uploads/ dans le nouveau. Je copie aussi les fichiers de tous les plugins et thèmes que je veux utiliser. C’est plus rapide qu’une installation par le tableau de bord.
Transférer les bons éléments de la base de données
Sauvegarder la base de donnée du site cible
Disons que son prefixe est ‘cible_ ‘.
Importer la base de données du multisite d’origine
En principe elle n’a pas les mêmes préfixes (‘source_’ ) et ne va pas supprimer les tables du site cible.
Supprimer les tables ‘source_’
Les seules qu’on conserve sont :
source_3_options ;
source_options ;
source_usermeta ;
source_users.
Supprimer les tables du site cible
On ne touche pas à cible_options, cible_usermeta et cible_users) et on supprime :
cible_comments
cible_links
cible_postmeta
cible_posts
cible_termmeta
cible_terms
cible_term_relationships
cible_term_taxonomy
Renommer les tables
source_comments en cible_comments
source_links en cible_links
source_postmeta en cible_postmeta
source_posts en cible_posts
source_termmeta en cible_termmeta
source_terms en cible_terms
source_term_relationships en cible_term_relationships
source_term_taxonomy en cible_term_taxonomy
Modifier à la main certaines entrées de cible_options
Il faut faire du sur mesure… Le site que je détricotais était heureusement très simple. J’ai simplement dû aller chercher dans la table source_3_options les valeurs des éléments qui nous semblent mériter d’être transféré et copier-coller la valeur dans l’option de même nom de la table cible_options .
Conserver une trace de certaines entrées
Certaines entrées n’existent pas encore puisqu’il faut activer le thème ou l’extension, puis faire une petite modification des réglages pour qu’elles se créent.
J’ai copié-collé dans un éditeur de texte les valeurs de current_theme, theme_mods_stargazer et cookie_notice_options pour les avoir plus tard.
Modifier les enregistrements DNS
Pointer le domaine subdomain.com vers le nouvel hébergement.
Avec whatsmydns.net, voir la propagation du nouveau DNS.
Créer le certificat Let’s encrypt de subdomain.com (en cochant l’option www).
Faire les derniers réglages
Pour une raison que j’ignore, Chrome conserve longtemps l’ancienne adresse IP du site. J’ai trouvé que c’était très irritant puis maintenant c’est très pratique !
Je tape subdomain.com dans firefox (réglé pour ne conserver aucun historique) et il affiche le nouveau site. Je peux me connecter à son tableau de bord.
Pendant ce temps, Chrome continue à afficher l’ancien site et si on se connecte, on se connecte à l’ancien tableau de bord. C’est pratique si on ne trouve pas les bonnes infos dans la base de données.
Modifier à la main les données
J’ai activé le thème stargazer puis fait une toute petite modification de son apparence. Ainsi, theme_mods_stargazer apparait maintenant dans cible_options. Je peux y copier-coller la valeur qui était dans la table du site source. Et automatiquement tous les réglages sont repris (sauf pour l’image de header, qu’il faut désactiver puis réactiver pour qu’elle s’affiche).
Dans les réglages de l’extension cookie-notice, j’ai également fait une toute petite modification. Dans la table cible_options, l’option cookie_notice_options est maintenant visible. Je peux aussi y copier-coller la valeur qui était dans la table source-options.
Pour le reste, j’ai copié-collé les réglages entre l’ancien site visible sur chrome et le nouveau visible sur firefox.
Rajouter les utilisateurs du site source
Il faut rajouter à la main les utilisateurs du site source. Comme on a conservé les tables source_3_usermeta et source_3_users, on peut assez facilement retrouver les bonnes informations.
Et malheureusement si l’id des users a changé, on risque d’être obligé d’aller réaffecter les contenus aux bons users…
Modifier wp-config.php et .htaccess
Vu que le site créé est crypté (certificat Let’s encrypt), il faut modifier certains éléments. Et je veux aussi interdire l’édition de fichiers dans le tableau de bord WordPress et limiter le nombre de révisions à 5.
Dans wp-config.php (avant la ligne /* That’s all, stop editing! Happy blogging. */ ), ajouter les lignes suivantes :
// Forcer l'accès SSL (https) pour le tableau de bord WordPress
define('FORCE_SSL_ADMIN', true);
// interdire l'édition de fichiers dans le tdb WordPress
define('DISALLOW_FILE_EDIT', TRUE);
define('WP_POST_REVISIONS', 5);
// max 5 stored revisions per posts
Et dans .htaccess, le contenu devrait être le suivant :
Une fois que la propagation des DNS est terminée (il vaut mieux attendre 24h), je peux supprimer le site dans son multisite source. Notre site est maintenant autonome.
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 !
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) :
rôle
adresse mail correspondante
Super administrateur
SUPER-ADMIN@PRINCIPAL.com
administrateur
ADMIN@PRINCIPAL.com
éditeur (ou autre)
EDITEUR@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.
rôle
adresse mail correspondante
éditeur (ou autre)
EDITEUR-SOUS@PRINCIPAL.com
Mon site de test est composé de trois sites :
le site principal, potentiel-web.com
un site secondaire, test1.potentiel-web.com
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 :
Super administrateur
super-admin[a]potentiel-web.com
administrateur
admin[a]potentiel-web.com
éditeur
editeur[a]potentiel-web.com
Pour test1.potentiel-web.com
éditeur
editeur-test1[a]potentiel-web.com
Pour test1.parcours-performance.com, j’utilise le nom de domaine principal, pas celui du site principal.
éditeur
editeur-test1[a]parcours-performance.com
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…
Je souhaite transformer un site existant (https) en un site multisite WordPress. En principe, c’est exactement comme ce que j’ai fait avec le site de test dans le premier article de cette série. La seule différence, c’est que je ne peux pas me permettre d’erreur puisque le site est utilisé…
Je fais comme indiqué dans le premier article de cette série WordPress Multisite sur OVH mutualisé, avec en plus des sauvagardes et la gestion des extensions existantes.
Sauvegarder les éléments du site existant
En premier, faire une sauvegarde de la base de données du site et la conserver dans un endroit sûr.
Avec Filezilla ou équivalent, faire une copie des fichiers .htaccess (en .htaccessOLD) et wp-config.php (en wp-configOLD.php).
Dans le tableau de bord WordPress du site existant, aller dans le menu « extensions » puis choisir la vue « extensions activées ». Copier le tableau dans Word ou autre pour disposer d’une liste de toutes les extensions activées du site.
Transformer le site en site multisite WordPress
Ca fonctionne exactement comme dans l’article « Un site ‘multisite’ WordPress sur OVH mutualisé ».
(1) Dans wp-config.php , j’ajoute les deux lignes suivantes :
Dans le tableau de bord WordPress, (2) je désactive toutes les extensions puis je vais dans le menu « outils » > « création du réseau ». Là je ne peux que choisir « sous-domaines », je met mes coordonnées d’administrateur comme nom de super-administrateur et je sauvegarde.
(3) Je modifie wp-config.phppour que les lignes correspondant aux multisite soient maintenant (attention dans la ligne 6 surlignée, le nom du domaine doit être le bon) :
(4) Je modifie .htaccess qui contient maintenant (c’est un site en https) :
# 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
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
(5) Je me reconnecte au tableau de bord WordPress du site.
Je sélectionne toutes les extensions qui doivent être réactivées puis (6), je les active pour les reseau.
Je vérifie et tout va bien. Du point de vue de l’internaute, le site est comme avant. Evidemment, du point de vue de l’administrateur devenu super-administrateur, il y a quelques changements.
Et maintenant ?
Il faut que je voies quelles sont les différences entre ‘super-administrateur’ et ‘administrateur’ pour voir quels sont les points de vigilance à prévoir. Ce sera l’objet d’un autre article de cette série WordPress Multisite sur OVH mutualisé.
Dans le premier article de cette série « WordPress Multisite sur OVH mutualisé« , nous avons vu comment créer un réseau de sites sur une seule installation de WordPress et une seule base de données. Jusqu’à présent, les sites du réseau ont tous une url sous la forme d’un sous-domaine du site principal (http(s)://prefix.domain-principal.com et le site principal est http(s)://domain-principal.com). Je veux qu’un des sites du réseau utilise un autre nom de domaine, et pas un sous-domaine du domaine principal.
Pour celà, l’usage est d’utiliser une extension de « domain mapping », telle que WordPress MU Domain Mapping. Dans ce billet, je vais parler de cette extension et d’une méthode encore plus simple.
Préparation du nom de domaine à associer
Le site WordPress multisite dans lequel je veux insérer un nouveau domaine est dans un répertoire intitulé « multi-test ». Le domaine que je veux y insérer est test1.parcours-performance.com
Sur l’espace client OVH, dans l’hébergement qui contient le multisite, cliquer sur l’onglet « multisites » puis sur le bouton « ajouter un domaine ou un sous-domaine ».
Là je n’aurais pas dû cocher « créer également … www… ». Je l’ai supprimé après pour ne pas multiplier les noms de domaine dans mon espace client…
Mon site WordPress multisite avant
J’ai déjà créé les sites test1.potentiel-web.com et test2.potentiel-web.com selon la méthodologie décrite dans l’article précédent de cette série WordPress Multisite sur OVH mutualisé. Je vais les laisser tels quels.
Je pars donc d’un réseau de sites contenant 3 sites :
le site principal (potentiel-web.com)
deux sites ayant pour nom un sous-domaine du site principal (test1.potentiel-web.com et test2.potentiel-web.com).
Je viens de créer un sous-domaine, test1.parcours-performance.com, dans mon espace client OVH et il est relié à l’hébergement du multisite.
J’ai maintenant deux options pour créer un site dans le réseau multisite :
Sans extension – c’est la solution que je recommande.
Avec une extension de « domain mapping »
On installe WordPress MU Domain Mapping de façon normale avec « admin du réseau » > « extensions » > « ajouter » puis on cliquer sur « activer sur le réseau ».
Avec Filezilla (ou autre client FTP), aller dans /multi-test/wp-content/plugins/wordpress-mu-domain-mapping et déplacer sunrise.php pour le mettre dans /multi-test/wp-content .
éditer wp-config.php et décommenter ou ajouter la ligne suivante, au dessus de dernier « require_once ».
/* for the multisite WordPress MU Domain Mapping extension */
define( 'SUNRISE', 'on' );
Réglages de l’extension
Dans « admin du réseau » > « Tableau de bord », on voit dans les menus à gauche « Réglages ». Cliquer sur son sous-menu « domain mapping ».
L’adresse IP se trouve à droite du nom de l’hébergement dans l’espace client OVH. Dans WordPress, « Réglages » > « Domains », on saisit cette adresse IP puis on définit les options du domaine.
Spontanément, je n’aurais coché que la case 2, comme dans la copie d’écran ci-dessus.
Mais après quelques essais, j’ai vu que je dois cocher la case 5, « Disable primary domain check. Sites will not redirect to one domain name. May cause duplicate content issues.« . En effet, si j’utilise des domaines externes (qui ne sont pas des sous-domaines du site principal), l’internaute voit le nom du site d’origine car la redirection est visible. Ainsi, après avoir « mappé » https://test1.parcours-performance.com à https://test2.potentiel-web.com (opération décrite plus loin), si je tape https://test1.parcours-performance.com dans un navigateur, le site s’ouvre mais l’url visible est devenue https://test2.potentiel-web.com…
Il faut donc cocher la case 5 si on veut que la redirection soit invisible pour les internautes.
Je coche donc les cases 2 et 5.
Mapper un site à un autre
En tant que super administrateur, je vais dans « admin du réseau » > « Sites » et je vois la liste des sites déjà créés :
Lorsqu’on passe la souris sur le nom d’un des sites, son adresse complète apparaît tout en bas du navigateur et on peut relever son ID :
Ici le site test1.potentiel-web.com affiche l’adresse « https://potentiel-web.com/wp-admin/network/site-info.php?id=3 ». L’ID est donc 3.
Maintenant, je vais dans « Réglages » > « Domains » et pour l’ID 3, je définis le domaine comme « test1.parcours-performance.com » :
Ensuite si je retourne dans la liste des sites et que je cliques sur « modifier » en dessous de test1.potentiel-web.com, je vois que l’adresse du site est restée https://test1.potentiel-web.com/ mais la liste indique un « mapping » vers test1.parcours-performance.com
Dans un navigateur, si je tape :
https://test1.potentiel-web.com/ m’affiche le site correspondant, dont le titre est test 1;
https://test1.parcours-performance.com, j’accède bien au site correspondant (dont le titre est toujours test1…) et son url visible dans le navigateur est restée https://test1.parcours-performance.com, si j’ai coché la case 5 des options de domaine (voir réglages ci-dessus).
Bilan de cette solution avec extension
Cette solution parait simple mais elle a deux inconvénients majeurs selon moi :
on est obligé de cocher l’option 5 si on veut que l’internaute ne voit pas la redirection. Ca génère un risque de contenu dupliqué pour les moteurs de recherche et ça ne me paraît pas acceptable.
Pour chaque domaine externe, on doit créer un sous-domaine du site principal ET le domaine externe. Ca prend un peu plus de temps et le risque d’erreur s’accroît.
C’est pour ces raisons que lorsque j’ai lu un sujet épinglé par l’auteur de l’extension qui expliquait qu’on n’a même pas besoin de l’extension, j’ai sauté dessus et je suis aller explorer la solution.
Sans extension – solution recommandée
créer un nouveau site
En tant que super administrateur, je vais dans « admin du réseau » > « Sites » et je vois la liste des sites déjà créés :
Je veux créer un nouveau site dans le réseau, avec l’url https://test1.parcours-performance.com. Dans la fenêtre des sites, je clique sur « ajouter » et je définis l’adresse web du site à RIEN (!) :
J’ai créé un site rien.potentiel-web.com, qui ne peut évidemment pas fonctionner puisque je n’ai pas créé ce sous-domaine dans mon espace client OVH. Il est visible dans la liste des sites du réseau WordPress :
Si je passe ma souris sur rien.potentiel-web.com, je vois apparaître « modifier ». Je clique dessus et dans « adresse web du site (URL) je remplace http://rien.potentiel-web.com/ par https://test1.parcours-performance.com. Après avoir sauvegardé la modification, je peux visiter le site et il fonctionne :
Maintenant un internaute peut accéder au site https://test1.parcours-performance.com. Mais je ne peux pas accéder à son tableau de bord pour l’instant !
Régler wp-config.php
Je ne peux pas accéder au tableau de bord du nouveau site car il y a un problème de « cookies » qui interdit la connexion. Dans le navigateur Chrome ou Firefox, j’obtiens un message « ERREUR les cookies sont bloqués ou ne sont pas reconnus par votre navigateur ». La seule solution est de modifier wp-config.php comme indiqué dans cet article de Tom McFarlin.
Dasn wp-config.php, les lignes relatives au multisite sont maintenant les suivantes, avec les 4 lignes surlignées qui règlent le problème de cookies :
Dans le tableau de bord WordPress, je supprime le site test2.potentiel-web.com mais je le laisse associé à l’hébergement potentiel-web.com dans mon espace client OVH.
Si je tape https://test2.potentiel-web.com dans un navigateur, je suis redirigée vers l’url https://potentiel-web.com/wp-signup.php?new=test2
Si je ne suis pas connectée en tant que super administrateur (c’est le cas dans le navigateur Firefox ci-dessous), je tombe sur une page m’informant que les inscriptions sont désactivées.
Lorsque les inscriptions sont désactivées, c’est que dans le tableau de bord du réseau de site, dans Réglages > Réglages du réseau, j’ai coché la case « Les inscriptions ne sont pas autorisées pour le moment ». Comme je ne prévois pas de laisser des utilisateurs externes créer des sites, et que mon hébergement OVH me contraint à aller créer les noms de domaine un à un (pas de « wildcard » *), je n’ai aucun intérêt à changer ce réglage.
Et maintenant ?
Dans les prochains articles de cette série WordPress Multisite sur OVH mutualisé, nous verrons comment sauvegarder un multisite, y insérer un site existant ou en sortir un.
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 :
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 :
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.
du code qu’il faudra ajouter à wp-config.php
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);
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
Attention : si on utilise un certificat SSL pour le site principal, voire pour les sites du réseau, il y a des spécificités. Voir plus bas le chapitre « Spécificités du SSL (https) »
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 :
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)
Commentaires récents