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é.
Je progresse en informatique et en développement web mais j’aimerais pouvoir mesurer où j’en suis et ce qu’il me reste à apprendre. J’entreprends donc de dresser la liste des connaissances et compétences d’un bon développeur web. Cette liste me servira ensuite pour définir mes prochaines actions d’amélioration.
Capacité à entrer en relation avec les autres (empathie, communication, …)
Gestion du stress
Gestion du temps
Prendre du recul : pourquoi je fais ça, qu’est-ce que je fais au delà des tâches concrètes ? Ca peut-être « je résoud des problèmes complexes et intéressants », « je travaille dans un environnement intellectuellement stimulant », « je construis des choses qui me plaisent », …
identifier ce qui apportera de la valeur au client (et donc aux clients du client)
identifier le niveau d’expertise que peut atteindre le client pour créer un site toujours actuel (si possible souvent actualisé) sans recourir à des compétences trop coûteuses pour celà
Définir ce que l’internaute voudra (conception de l’interface utilisateur)
pas de peur d’échouer au point que ça bloque les approches créatives et nouvelles, mais assez pour faire des tests sérieux.
L’aptitude au code
Source : https://medium.com/@sgarcia.dev/
Maîtrise des « langages »
Maîtriser la programmation (hors syntaxe)
Maîtrise des concepts de l’informatique tels que Model – View – Controller, Programmation orientée objet, …)
Savoir créer des algorithmes
Maîtrise des outils actuels de base
des langages sous-jacents tels que PHP (côté serveur), Javascript (côté client), SQL pour les bases de données ;
du codage de pages web (html5, css3, ….) ;
des outils de test : du code, des caractéristiques responsive, firebug ou chrome dev tools, des rendus sur des moteurs différents (Gecko tel que Firefox, WebKit tel que Safari, Chrome, Internet Explorer et Opera) ;
Autres tels que utilisation de SVG.
Maîtrise d’outils plus sophistiqués
des outils d’automatisation tels que Sass & Less, Grunt & Gulp (ces deux derniers nécessitent de savoir faire fonctionner NodeJS) ;
compréhension du DOM (document Object model) et d’AJAX
utilisation de Ruby, angularJS, REACT (voir son utilisation avec l’API Rest de WordPress dans Building a better WordPress) & Redux
Sur la gestion de versions avec Git, Try Github (cours gratuit sur CodeSchool) et le tutoriel très complet Become a git guru;
Les tutoriels de Scotch.io’s sur Grunt et Gulp, qui permettent, entre autres, de compiler des fichiers LESS ou SASS, de minimiser des fichiers JS ou CSS,
Je liste quelques pistes, que je vais explorer :
créer un profil stackoverflow et commencer à aider d’autres personnes à résoudre des problèmes ;
lire attentivement , suivre tous les liens et identifier ce que je sais / ne sais pas
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.
Nous allons améliorer la page de réglage de notre extension WordPress, en y ajoutant un champ de type « color picker » et en affichant les données complémentaires définies avec les champs. Dans les articles précédents de cette série (Un plugin WordPress avec page de réglage), nous avons progressivement construit l’extension et sa page de réglage. A la fin du précédent article, l’extension correspondait au contenu de ce fichier zip : clea-add-button avec éditeur wp_editor (zip).
Que voulons-nous faire ?
Notre page de réglages est capable d’afficher tous les types de champs sauf les choix de couleur. Nous voulons donc pouvoir choisir une couleur et même définir son opacité. Et pour simplifier la vie de l’administrateur du site, il faut qu’on lui dise quelles sont les couleurs utilisées par son thème, en les intégrant dans une palette sous le color picker.
Par ailleurs, notre page de réglages devra afficher les éléments complémentaires définis pour chaque champs, tels que « helper » qui contient un texte d’aide complémentaire.
Identifier les couleurs utilisées par le site
Les paramètres du thème courant sont stockés par WordPress et récupérables avec la fonction get_theme_mods(). Cette fonction nous donne un array contenant tous les paramètres, dont certains sont des couleurs.
Nous lisons donc l’array et pour chaque valeur, nous regardons s’il s’agit d’une couleur avec la fonction sanitize_hex_color_no_hash(). Cette fonction renvoie « NULL » si elle ne trouve pas un élément en hexadécimal à 3 ou 6 caractères. A chaque fois qu’elle trouve un élément non NULL, on le place dans l’array qui sera retourné pour former notre palette de couleurs.
/**********************************************************************
* find the colors used in the website's theme
**********************************************************************/
function clea_presentation_get_current_colors() {
// to get all the current theme data in an array
$mods = get_theme_mods();
$color = array() ;
foreach ( $mods as $key => $values ) {
if ( !is_array( $values ) ) {
if ( is_string( $values ) && trim( $values ) != '' ) {
$hex = sanitize_hex_color_no_hash( $values ) ;
if ( trim( $hex ) != '' ) {
$color[ $key ] = $hex ;
}
}
}
}
// remove duplicate colors
$current_colors = array_unique( $current_colors ) ;
return $color ;
}
Pour vérifier que c’est une bonne solution, , nous ajoutons le code suivant à la fonction clea_add_button_options_page() :
case 'color' :
// get the colors used by the theme
$current_colors = clea_presentation_get_current_colors() ;
$data_palette = "";
// the color palette must be a string with colors and | separator
// "#222|#444|#00CC22|rgba(72,168,42,0.4)" would be ok
foreach ( $current_colors as $color ) {
$data_palette .= $color . '|' ;
}
$data_palette = rtrim( $data_palette, '|' ) ;
// uses https://github.com/BraadMartin/components/tree/master/alpha-color-picker
printf( '<input type="text" class="alpha-color-picker" name="%2$s" value="%1$s" data-palette="%5$s" data-default-color="%4$s" data-show-opacity="true" />', sanitize_text_field( $value ), $name, $field, $arguments['default'], $data_palette ) ;
break ;
A ce stade, celà affiche un champs de type ‘text’ avec à l’intérieur la couleur par défaut définie dans le champs. Il nous faut maintenant ajouter la feuille de style et le programme javascript conçus par le créateur de l’Alpha color Picker et un petit script en JQuery.
Les compléments à intégrer dans notre extension
Dans le répertoire « /admin » du plugin, créer les sous-répertoires « /css » et « /js « .
Télécharger le fichier zip du dépôt « components » de Braad Martin ici sur un PC. Décompresser le fichier zip puis dans le sous-répertoire « alpha-color-picker » copier alpha-color-picker.css et alpha-color-picker.js respectivement dans les répertoires /admin/css et /admin/js de l’extension.
Les fichiers à créer
Nous devons créer deux fichiers :
un fichier (clea-add-button-color-trigger.js par exemple) qui contiendra le JQuery nécessaire à l’affichage
un fichier (clea-add-button-admin-enqueue.php par exemple) qui sera appelé par le fichier principal de l’extension et qui chargera la feuille de style et les scripts JavaScript nécessaires.
Le fichier /admin/js/clea-add-button-color-trigger.js contient :
Quant au fichier /admin/js/clea-add-button-admin-enqueue.php , il contient
add_action( 'admin_enqueue_scripts', 'clea_add_button_admin_enqueue_scripts' );
function clea_add_button_admin_enqueue_scripts( $hook ) {
// to find the right name, go to the settings page and inspect it
// the name is somewhere in the <body class="">
// it will always begin with settings_page_
if( 'settings_page_my-plugin' != $hook ) {
// echo "not the right page, this is : " ;
// echo $hook ;
return;
}
// for the alpha color picker
// source : https://github.com/BraadMartin/components/tree/master/alpha-color-picker
wp_enqueue_style(
'alpha-color-picker',
CLEA_ADD_BUTTON_DIR_URL . '/admin/css/alpha-color-picker.css',
array( 'wp-color-picker' ) // You must include these here.
);
wp_enqueue_script(
'alpha-color-picker',
CLEA_ADD_BUTTON_DIR_URL . '/admin/js/alpha-color-picker.js',
array( 'jquery', 'wp-color-picker' ), // You must include these here.
null,
true
);
// This is the JS file that will contain the trigger script.
// Set alpha-color-picker as a dependency here.
wp_enqueue_script(
'clea-add-button-admin-color-js',
CLEA_ADD_BUTTON_DIR_URL . '/admin/js/clea-add-button-color-trigger.js',
array( 'alpha-color-picker' ),
null,
true
);
}
La condition if( ‘settings_page_my-plugin’ != $hook ) permet de ne pas charger le style et le JavaScript si on n’est pas sur la page d’options de notre extension.
Enfin, dans clea-add-button.php , nous ajoutons la ligne qui démarrera clea-add-button-admin-enqueue.php :
// load styles and scripts for the admin
require_once CLEA_ADD_BUTTON_DIR_PATH . 'admin/clea-add-button-admin-enqueue.php';
le résultat
Notre page d’option affiche maintenant la couleur par défaut sous une forme différente :
Le champ « color » affiche bien une couleur maintenant.
Si on clique sur la couleur, un « color picker » s’ouvre. Il affiche la couleur par défaut définie dans le champ 3. On observe qu’il y a une palette de couleur en dessous, qui correspond effectivement aux couleurs du thème sur lequel j’essaie cette extension. Et en dessous, on voit une barre qui permet de gérer la transparence de la couleur choisie.
Le champ « color » affiche un « color picker » complet.
Ici nous sélectionnons la couleur orange du thème et nous demandons à ce que sa transparence soit 71%.
Choix d’une couleur de la palette puis réglage de la transparence
Ca fonctionne parfaitement et la nouvelle couleur s’enregistre correctement.
Afficher les informations complémentaires
Chaque champ affiché dans notre page d’options est défini par un array :
Nous utilisons toutes les clés de cet array sauf deux (‘label’ et ‘helper’). Ces deux clés contiennent respectivement le texte à afficher systématiquement pour expliciter ce qu’il faut faire et un texte d’aide complémentaire.
Pour l’afficher, avant le champs à remplir, j’ajoute le code suivant dans la fonction clea_add_button_settings_field_callback( $arguments ) :
// If there is a help text and / or description
printf( '<span class="field_desc">' ) ;
if( isset( $arguments['helper'] ) && $helper = $arguments['helper'] ){
printf( '<img src="%1$s/images/question-mark.png" class="alignleft" id="helper" alt="help" title="%2$s" data-pin-nopin="true">',CLEA_ADD_BUTTON_DIR_URL, $helper ) ;
}
// If there is a description
if( isset( $arguments['label'] ) && $description = $arguments['label'] ){
printf( ' %s', $description ); // Show it
}
printf( '</span>' ) ;
La condition if( isset( $arguments[‘helper’] ) && $helper = $arguments[‘helper’] ) vérifie que $arguments[‘helper’] est défini ET qu’il n’est pas vide.
J’ai placé un fichier question-mark.png dans le répertoire /images de l’extension.
Le résultat n’est pas très joli :
Il faut donc que j’ajoute une feuille de style pour améliorer la page d’options.
Créer une feuille de style pour la page d’options
Dans le fichier /admin/js/clea-add-button-admin-enqueue.php , nous ajoutons une ligne pour charger la feuille de style de notre page de réglages :
Notre page de réglages fonctionne. Il ne reste plus que quelques améliorations à apporter. Ce sera l’objet du prochain article de cette série, Un plugin WordPress avec page de réglage.
Sauvegarder la base de données du site !
Commentaires récents