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.
Dans un précédent article (WordPress avec un SSL Let’s encrypt sur OVH mutualisé) j’ai exploré la création de zéro d’un site encrypté. Maintenant, je veux voir ce qu’il se passe si je transforme un site existant.
Pour minimiser les risques, j’ai cloné un site existant http://monsite.com dans http://prefix.monsite.com. J’ai d’abord essayé tout ce qui suit avant de le refaire sur un site opérationnel. Et je recommande à toute personne qui veut faire la même chose de faire d’abord un essai sur un site sans risque avant de se lancer sur un site en activité.
Quelques lectures avant de commencer !
Avant de démarrer, j’ai lu les 2 documents suivants :
Nota 1 : Dans l’article de référence, une bonne partie des 23 actions concernent les CDN (content delivery network selon Wikipedia). Comme je ne suis pas concernée, je les ai shuntées. Mais j’y ai ajoutée la création du certificat SSL.
Nota 2 : pour un site qui utilise un cache, il faut le vider avant de procéder aux étapes qui suivent.
Pour chaque domaine et sous-domaine concerné, dans hébergement, onglet « multisite », j’édite le nom de domaine et je coche SSL. ATTENTION : il faut impérativement que le sous-domaine www soit également couvert par le certificat si on veut ensuite pouvoir faire une rédirection de www vers non www (ça n’est pas logique mais c’est comme ça) ! Une fois que j’ai modifié tous les domaines, je clique sur le bouton « régénérer le certificat ssl ». Si on vient juste de créer un domaine ou d’activer le ssl sur un domaine, il fautattendre plusieurs heures avant que le site puisse être lu en https.
A ce stade, si on ne fait pas les étapes suivantes, le site fonctionne parfaitement en http (http://nom-de-mon-site.com). On a intérêt à attendre que le certificat SSL soit régénéré avant de commencer les étapes suivantes.
Une fois que le certificat SSL est régénéré, si on tape https://nom-de-mon-site.com, le site s’affiche sans message d’erreur mais il n’y a pas le petit verrou vert à gauche du lien. Avec l’inspecteur de Chrome, je vois qu’il y a du « mixed content« . Le site est en https mais fait appel à des contenus issus de http. Le navigateur considère que le site n’est pas complètement sécurisé. Nous allons donc supprimer ces liens http et les remplacer par des https.
L’extraire et placer le répertoire Search-Replace-DB-master dans un sous-répertoire du répertoire WordPress du site à modifier, c’est à dire un répertoire au même niveau que wp-content, wp-admin ou wp-includes. Renommer le répertoire, de Search-Replace-DB-master vers par exemple migrer comme dans la copie d’écran à droite.
On lance le script en tapant http://nom-de-mon-site.com/migrer/
On cherche http://nom-de-mon-site.com, à remplacer par https://nom-de-mon-site.com
Lancer dryrun pour voir ce qui va être modifier sans procéder à la modification
Si tout semble correct (et que la base de données a été sauvegardée avant), lancer « live run » pour réaliser effectivement les modifications. Dans mon cas, 712 entrées ont été modifiées.
Lorsqu’on a cloné un autre site, il est utile aussi de remplacer d’éventuels liens vers l’autre site par https://nom-de-mon-site.com. Dans mon cas, ça a modifié 8294 entrées.
Ca y est, le petit verrou vert est maintenant à gauche du lien lorsque je visionne https://nom-de-mon-site.com !
Si vous avez du « mixed content », la solution merveilleuseest whynopadlock, qui scanne le site et nous dit quels sont les contenus en http et ce qui les charge.
Mais si je clique sur un article du site de test, j’ai un message d’erreur indiquant que le lien n’existe pas.
SUPPRIMER le répertoire « migrer » avant de continuer !
étape 3 : changer les adresses du site
Dans le tableau de bord WordPress, menu « Réglages » > « Général », modifier les liens « Adresse web de WordPress (URL) » et « Adresse web du site (URL) » en remplaçant l’adresse http par https.
Si on rafraichit (F5) le navigateur, les liens du site devraient fonctionner mais ce n’est pas le cas. Il faudra attendre l’étape 5 pour que ça fonctionne !
étape 4 : mise à jour des permaliens
Dans le tableau de bord WordPress, menu « Réglages » > « Permaliens », vérifier que la case cochée est la bonne puis cliquer sur « enregistrer les modifications », même si on n’en a pas fait.
Si on rafraichit (F5) le navigateur, les liens du site devraient fonctionner mais ce n’est pas le cas. Il faudra attendre l’étape 5 pour que ça fonctionne !
étape 5 : MAJ des librairies JS ou Ajax
J’ai vérifié avec les parties « scripts » et « styles » de l’extension Query Monitor (cf cet article, sur ce site, sur les outils de débogage) et aucun script ou style externe n’est appelé par une url non encryptée. Je n’ai donc pas besoin de réaliser cette étape.
étape 6 : ajouter des redirections 301
On veut que les sites en www.mondomaine.com soient redirigés vers https://mondomaine.com et que les http:// soient redirigés vers https.
Pour celà, ajouter ces instructions dans le fichier .htaccess, au dessus de la ligne # BEGIN WordPress :
Note : Cette instruction ne fonctionne que si le certificat ssl a également été généré pour la version www du site.
Le meilleur moyen de vérifier est de cliquer sur un élément du menu vers une page existante. Elle va s’afficher en https. Ensuite, dans le navigateur, enlever « https:// » et taper <entrée>. L’adresse non https entrée doit renvoyer vers l’adresse https.
Et voilà, mon site fonctionne correctement en https !
étape 7 : forcer l’accès SSL pour l’admin
Dans wp-config.php, ajouter les lignes
/* HTTPS only for admin access and login */
define( 'FORCE_SSL_ADMIN', true );
Ainsi, personne ne pourra accéder au tableau de bord WordPress en mode non sécurisé et tous les login seront en https.
A ce stade le site est parfaitement configurer pour fonctionner de manière sécurisée.
étape 8 : régler les réseaux sociaux et autres
Ma référence est toujours l’article How to Migrate from HTTP to HTTPS – Complete Tutorial et je suis sur un site réel, auquel des réseaux sociaux font des liens, que google analytics suit et qui est paramétré dans Google Webmaster Tools.
mettre à jour les sitemaps
Avec Yoast SEO, les sitemaps sont maintenant automatiquement en https, par exemple « https://nom-de-mon-site.com/page-sitemap.xml ».
Mettre à jour le compte Google Analytics
Dans votre compte Google Analytics, il faut modifier l’url du site.
Cliquer sur l’onglet « Administration ». Dans cet onglet, on voit trois colonnes, « compte », « propriété » et « vue ».
Dans la colonne « propriété », cliquer sur « Paramètres de la propriété ». Modifier l’adresse du site comme sur la copie d’écran à droite puis cliquer sur « enregistrer ». Comme ça on ne perd pas l’historique de l’ancien site non sécurisé. Attention, dans le cas présent, j’ai dû régler « vue par défaut », juste en dessous à « toutes les données du site web » pour que ça fonctionne correctement (affichage « opération réussie » après avoir cliqué sur « enregistrer »).
Faire la même chose dans la colonne « vue », en cliquant sur « Paramètres de la vue » pour modifier l’adresse du site.
Dans la colonne « propriété », cliquer sur « Paramètres de la propriété », puis tout en bas, dans « Paramétrer la search console », vérifier que c’est bien le site en https qui est la cible. Cette opération relie les comptes google webmasters tools et google analytics du site.
Attention, on reçoit un message disant que l’ancien site (http) est déconnecté. Il ne faut pas en tenir compte.
créer un nouveau site sur google webmaster tools
Il semblerait que l’on soit obligé de faire ça. Dans Google Webmaster Tools, ajouter un nouveau site en cliquant sur le bouton « ajouter une propriété ». On ajoute le site https://nom-de-mon-site.com. Ensuite, on suit les instructions reçues dans un mail. En particulier, il faut sélectionner le pays cible.
Soumettre les sitemaps à Google Webmaster tools
Il faut soumettre les sitemaps à Google Webmaster tools pour le nouveau site en https. On vérifie ainsi qu’il n’y a pas d’erreurs.
Vérifier que les robots peuvent circuler dans le site
Dans le menu « explorer » > « explorer comme Google » de Google Webmasters Tools, cliquer sur le bouton « explorer ». Il ne doit pas y avoir d’erreur.
Il pourrait être utile de cliquer ensuite sur « envoyer pour indexation » mais je ne le fais pas…
Soumettre les sitemaps à d’autres moteurs de recherche
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)
Dans les articles précédents de cette série (Un plugin WordPress avec page de réglage), nousavons construit les fondements d’une extension correcte, avec une page de réglages qui fonctionne correctement. Je veux maintenant modifier trois détails pour que cette extension serve plus facilement de base à d’autres extension :
si un champs est de type « url » ou « email », il faudra qu’il y ait validation que les valeurs saisies sont bien soit des url soit des adresses mail ;
Ajouter un champs de type « date » ;
Les données à modifier pour adapter les bases de l’extension devraient être dans un fichier distinct, avec des commentaires pour faciliter l’adaptation par le développeur.
Nous allons réaliser toutes ces opérations, en commençant par la dernière.
déplacer les données variables dans un autre fichier
Dans clea-add-button.php , ajouter les lignes suivantes :
// the sections and fields data for the settings page.
require_once CLEA_ADD_BUTTON_DIR_PATH . 'admin/clea-add-button-admin-settings.php';
On dit donc au script principal de notre extension qu’il devra utiliser le script contenu dans /admin/clea-add-button-admin-settings.php . Ce script contient deux fonctions qui retournent respectivement le contenu des arrays de définition des sections et des champs. J’y ai simplement copié les deux fonctions clea_add_button_settings_sections_val() et clea_add_button_settings_fields_val() qui étaient auparavant à la fin du fichier clea-add-button-settings-page.php .
Attention : le fichier doit être encodé en utf-8 avant d’y écrire des caractères accentués en français par exemple. Sinon les texte sont affichés avec des � à la place des caractères « spéciaux ».
Maintenant dans clea-add-button-settings-page.php , il faut que je dise comment traiter les champs de type « date-picker ». Dans la fonction clea_add_button_settings_field_callback( $arguments ) , j’ajoute un cas « date-picker » :
A ma grande surprise, je n’ai même pas eu à ajouter quoi que ce soit d’autre. Je m’attendais pourtant à devoir charger jquery-ui-datepicker pour cette page et aussi à devoir créer une fonction…
Si on veut ajouter des options, on pourra s’inspirer des deux articles suivants :
On peut avoir à demander une adresse mail ou le lien d’un site internet. Dans ce cas, la validation et la sanitation du contenu du champs ne se font pas de la même manière que pour un simple texte.
La validation des champs est réalisée lorsqu’on affiche les champs. Jusqu’à présent l’utilisateur n’était pas informé s’il entrait une valeur non valide. C’est pourtant indispensable. Nous allons utiliser la fonction
La sanitation et l’affichage sont faits dans clea-add-button-settings-page.php , par le biais de la fonction clea_add_button_settings_field_callback( $arguments ) .
Commençons par ajouter deux nouveaux champs, de type ‘url’ et ’email’ dans la section 1, définis dans clea-add-button-admin-settings.php :
Il faut maintenant que nous les validions, que les « nettoyons » (sanitation) et que nous les affichions en sécurité. Tout se fait dans une fonction que l’on appelle lors de l’étape « register_setting().
Dans le fichier clea-add-button-settings-page.php , modifier la ligne qui réalise le « register_settings() » pour qu’elle appelle une nouvelle fonction :
Noter que l’affichage se fait en utilisant sanitize_email().
Si je tape une adresse email invalide (par exemple « rgdfghhr »), un message « You have entered an invalid e-mail address. » s’affiche en haut de la page de réglages lorsque je clique sur « enregistrer les modifications ».
Ca fonctionne mais le gros inconvénient est qu’il faudra aller modifier cette fonction à chaque fois qu’on change le nom ou le type d’un champ. Par exemple, si je décide que le champ ‘field-1-6′ s’appellera ’email’, il faudra que j’aille changer le contenu de la fonction clea_add_button_settings_validate_and_sanitize.
Il faut donc que cette sanitation et validation se fasse sans se référer explicitement à un nom de champ. Pour celà, on va utiliser l’array de définition des champs, comme on a fait dans la fonction clea_add_button_admin_init().
function clea_add_button_settings_validate_and_sanitize( $input ) {
$output = (array) get_option( 'my-plugin-settings' );
$set_fields = clea_add_button_settings_fields_val() ;
$types = array() ;
// create an array with field names and field types
foreach ( $set_fields as $fields ) {
foreach( $fields as $field ){
$types[ $field['field_id'] ] = $field['type'] ;
}
}
// now validate and sanitize each field
foreach ( $types as $key => $type ) {
switch( $type ){
case 'wysiwig' :
$output[ $key ] = wp_kses_post( $input[ $key ] ) ;
break ;
case 'email' :
if ( is_email( $input[ $key ] ) ) {
$output[ $key ] = $input[ $key ];
} else {
$message = __( 'You have entered an invalid e-mail address in : ', 'clea-add-button' ) ;
$message .= $key ;
add_settings_error( 'my-plugin-settings', 'invalid-email', $message );
}
break ;
default :
$output[ $key ] = sanitize_text_field( $input[ $key ] ) ;
}
}
return $output;
}
Au départ, je crée un array avec tous les noms de champs et leurs type, tels que définis dans la fonction clea_add_button_settings_fields_val() . Ensuite, pour chaque élément de cet array, nous faisons une sanitation et une validation différente selon son type.
Mettre à jour le numéro de version et le readme
Dans le fichier clea-add-button.php , j’ai modifié @version 0.3.0 . L’extension est maintenant en version 0.3.
Dans le README.md, j’ai ajouté la version 0.3 dans le « changelog » :
== Changelog ==
= 0.3 =
* the definition of sections and fields to display on the settings page is now in /admin/clea-add-button-admin-settings.php
* 3 new types of fields may be processed : date-picker, email and url
* validation and sanitation of user inputs is done and the user gets a notice in case of a bad email
L’extension de base finale, clea-plugin-boilerplate est passée en version 1 et disponible ici sur github. Elle est identique à clea-add-button sauf que les noms de fichiers, de fonctions et de variables ont été changés et qu’un fichier pot a été généré pour les traductions.
Et maintenant
Notre page de réglages fonctionne, quel que soit le type de champs que l’on souhaite afficher. Nous disposons maintenant d’une extension de base, correctement codée, que l’on peut utiliser comme base (boilerplate) n’importe quelle extension. C’est la fin de cette série, Un plugin WordPress avec page de réglage.
Les internautes, et les moteurs de recherche, attachent de plus en plus d’importance au petit cadenas vert qui indique qu’un site internet est sécurisé. Lorsque le site est sécurisé, les données bancaires, les données personnelles ou les mots de passe sont cryptés. Les données sont donc mieux protégées.
J’expérimente ici la création d’un site « https://potentiel-web.com » sur un hébergement Pro mutualisé d’OVH. Je vais utiliser un certificat gratuit « Let’s Encrypt », disponible depuis quelques mois sur OVH.
étape 0 : dans l’espace client OVH
Il faut que j’associe le domaine potentiel-web.com à un hébergement. Les éléments qui suivent sont décrits avec plus de détails dans l’article Hébergement Pro OVH avec plusieurs sites.
Dans l’hébergement cible, choisir l’onglet « multisite » et cliquer sur le bouton « Ajouter un domaine ou sous domaine ».
J’ajoute le domaine potentiel-web.com, déjà enregistré chez OVH et dans le second panneau de paramétrages, je choisis « créer également le sous domaine www.potentiel-web.com » et je coche l’option « SSL ». Dans le dernier panneau, je choisis « configuration automatique (recommandé) » et je valide.
Mon espace client affiche successivement « La modification du ou des domaines associé(s) à votre hébergement mutualisé est en cours … » puis « La modification du ou des domaines associé(s) à votre hébergement mutualisé a été effectuée avec succès. ».
Dans la liste des domaines de l’onglet multisites, je vois maintenant apparaître les deux sites (avec et sans www) :
Pour l’instant, je ne m’occupe pas du SSL en orange.
étape 1 : créer un site WordPress classique
Créer la base de données associée
dans l’espace client OVH, partie hébergement, je vais dans l’onglet « base de données » et je clique sur le bouton « créer une base de données ».
Une fois que j’ai reçu un mail m’informant de la création de la base, je peux continuer.
Installer le module WordPress
Toujours dans l’espace client OVH, partie hébergement, je vais dans l’onglet « modules en 1 clic » pour installer WordPress.
Je clique sur le bouton « ajouter un module ». Je choisis WordPress et potentiel-web.com comme domaine associé. Je clique sur « installer en mode avancé ».
Je reçois un mail d’OVH, avec le nom d’utilisateur et le mot de passe associé, lorsque le module est installé.
Accéder à WordPress
Je vérifie que j’accède au site http://potentiel-web.com et au tableau de bord WordPress (http://potentiel-web.com/wp-admin, avec le nom d’utilisateur et le mot de passe défini lors de l’installation du module).
J’en profite pour créer un autre utilisateur administrateur, dont le mot de passe n’aura pas été transmis par mail. Evidemment je supprime ensuite le précédent utilisateur.
étape 2 : gestion du certificat SSL
A ce stade, si je tape https://potentiel-web.com/ pour accéder à mon site, mon navigateur (chrome) m’affiche un message d’alerte.
Par contre, http://potentiel-web.com/ s’affiche correctement. C’est normal puisque je n’ai pas « généré de certificat SSL » lors de l’étape 0. Je ne l’ai pas fait car lorsque j’ai essayé, l’espace client d’OVH m’a affiché un message disant que si j’avais crée un nouveau site depuis moins de deux heures, le certificat ne fonctionnerait pas.
Dans mon espace client OVH, je clique sur l’hébergement de potentiel-web.com et j’accède à l’onglet « informations générales ».
Je clique sur « régénérer le certificat SSL ». Selon le guide OVH « Les certificats SSL sur les hébergements web« , il faut maintenant attendre le protocole HTTPS quelques heures, « le temps de le déployer sur l’ensemble del’infrastructure ».
Nota : pour un site existant, à transformer en https, le processus est légèrement différent, et également décrit dans le guide OVH ci-dessus.
Quelques heures plus tard, le site https://potentiel-web.com/ s’affiche correctement :
Redirection du http vers le https
Maintenant que le site fonctionne en https, il faut que j’élimine toute possibilité d’accéder en http :
pour éviter les problèmes de « duplicate contents » puisque les robots des moteurs de recherche considèrent les sites en http comme distincts des sites en https.
pour éviter aussi qu’un internaute se retrouve sur la version non sécurisée.
Pour y arriver, j’ai trois choses à faire :
régler le nom du site dans le tableau de bord WordPress ;
Modifier wp-config.php pour interdire l’accès au tableau de bord hors https
rediriger vers l’url en https avec .htaccess
Modifier le nom du site
Dans le tableau de bord WordPress, menu « Réglages » > « Général », régler « Adresse web de WordPress (URL) » et « Adresse web du site (URL) » pour qu’elles démarrent avec https et pas http.
Modifier wp-config.php
Modifier wp-config.php en y ajoutant :
/* HTTPS only for admin access and login */
define( 'FORCE_SSL_ADMIN', true );
define('FORCE_SSL_LOGIN', true);
Modifier le .htaccess
Ajouter :
# direct everything to https
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://%{SERVER_NAME}/$1 [R=301,L]
Il n’y a plus qu’à attendre un peu et ce sera bon ! Dans un navigateur, que l’on tape potentiel-web.com ou http://potentiel-web.com, on arrive dans tous les cas à https://potentiel-web.com.
Et maintenant ?
Je pense que la transformation d’un site existant doit être un peu différente, avec des problèmes spécifiques (cf le guide OVH, « Eviter les pièges du SSL avec mon siteweb« ). Il va donc falloir que je fasses des essais. Ce sera l’objet d’un autre article.
Commentaires récents