J’ai besoin d’utiliser un thème enfant du thème WordPress Twenty Seventeen. Dans cet article, j’explique comme le créer et le modifier légèrement. D’autres articles de cette série Un thème enfant de Twenty Seventeen expliqueront des modifications plus importantes.
Création d’un thème enfant
A l’aide de Filezilla (ou autre accès en FTP) créer un répertoire 2017-child dans wp-content/themes/ du site WordPress utilisé.
Y placer les trois fichiers suivants :
functions.php
style.css
screenshot.png (optionnel) : une image de votre choix, au format 600 px de large et 450 px de haut.
Dans functions.php, placer le code suivant (source Codex WordPress) :
<?php
add_action( 'wp_enqueue_scripts', 'tw17_child_enqueue_styles' );
function tw17_child_enqueue_styles() {
$parent_style = 'twentyseventeen-style-css'; // This is 'twentyfifteen-style' for the Twenty Fifteen theme.
wp_enqueue_style( $parent_style, get_template_directory_uri() . '/style.css' );
wp_enqueue_style( 'tw17-child-style',
get_stylesheet_directory_uri() . '/style.css',
array( $parent_style ),
wp_get_theme()->get('Version')
);
}
?>
Dans style.css , il doit y avoir l’en-tête suivant :
/*
Theme Name: Twenty Seventeen Child
Theme URI:
Description: Thème enfant de twenty seventeen
Author: ALD
Author URI: https://knowledge.parcours-performance.com/
Template: twentyseventeen
Version: 1.0.0
License: GNU General Public License v2 or later
License URI: http://www.gnu.org/licenses/gpl-2.0.html
Text Domain: Tw17-child
-------------------------------------------------------------- */
Et voilà, maintenant le tableau de bord WordPress me propose le thème « Twenty Seventeen Child ».
Modifier le contenu de la page d’accueil
Par défaut, le thème est réglé avec la page « Accueil » comme page d’accueil statique. Je n’y touche pas.
Par contre, je veux modifier le contenu automatique de cette page.
La page d’accueil statique de Twenty Seventeen
Elle contient d’abord le contenu de la page réglée comme page d’accueil statique puis les contenus des 4 sections définies dans le menu « apparence / Personnaliser / Options du thème ».
Je crée 4 pages, intitulées « Caméra », « Nest », « Eedomus » et « Autres » et je les publie.
Ensuite dans le tableau de bord WordPress, je choisis « apparence / Personnaliser / Options du thème » puis j’affecte chacune des pages créées à l’une des 4 sections.
A l’aide de Filezilla (ou autre accès en FTP) copier le fichier page.php du thème Twenty Seventeen (répertoire wp-content/themes/twentyseventeen ).
Placer ce fichier dans un répertoire pages dans wp-content/themes/2017-child/ du site WordPress utilisé. Le renommer (pour moi al-dashboard-1.php) et en modifier le contenu pour que l’en-tête contienne un « template name » :
Maintenant, si je vais modifier (ou créer) une page dans le site, dans la barre latérale de droite, dans le bloc « Attributs de la page », la liste déroulante « modèles » me propose « maquette section 1 (caméra) ».
Mais attention, si cette page doit être insérée dans la page d’accueil, seul le contenu créé avec l’éditeur WordPress s’affiche…
Et maintenant ?
Je vais utiliser ce thème enfant pour construire un tableau de bord domotique pour ma maison. J’en explique les étapes de construction dans la série d’article Un tableau de bord domotique. Lorsque je ferai des modifications du thème enfant que je viens de créer, je les expliquerai dans les articles suivants de cette série Un thème enfant de Twenty Seventeen
Excédée par le mauvais fonctionnement du serveur cloud managé de mon ancien fournisseur, je me suis tournée vers l’offre d’Infomaniak. Je suis stupéfaite par la clarté et la simplicité d’accès. Les prix sont plus élevés mais comme je dispose d’une solution satisfaisante de sauvegardes, je n’ai plus besoin d’acheter une solution complémentaire. Je m’y retrouve donc.
J’explique ici comment transférer un site existant vers son nouvel hébergement. Cet article est rédigé comme aide-mémoire pour moi mais il pourra également être utile à d’autres.
Situation initiale
Domaine testal.com géré par OVH, avec un hébergement sur un serveur cloud OVH. Le site est sous WordPress, avec un certificat SSL.
Je laisse les domaines sur OVH mais je transfère les sites sur des hébergements d’un serveur cloud managé d’Infomaniak.
Les grandes lignes du transfert
On procède en grandes étapes :
sauvegarde des fichiers spécifiques et de la base de données du site initial ;
création d’un site WordPress « blanc » sur l’hébergement Infomaniak ;
Réglages du site WordPress Infomaniak ;
Pointage des DNS vers le nouvel hébergement ;
Activation d’un certificat SSL Let’s Encrypt.
C’est seulement durant la quatrième étape que les internautes sont dirigés vers la nouvelle version du site. Pendant la phase de réglages du site, on peut y accéder (visualisation et tableau de bord WordPress) grâce à un lien de prévisualisation très efficace.
Au fur et à mesure du processus, on note les informations importantes dans un fichier, par exemple la check-list de transfert que j’ai créée en divers formats :
On veut conserver des fichiers spécifiques et la base de données.
Dans l’ancien hébergement, sauvegarder le contenu de wp-content (hors sauvegardes, on peut zapper les répertoires « langages », « cache » et « upgrade » ) et la base de données (avec un dump, ou directement via phpMyAdmin de l’hébergeur).
On a donc deux fichiers :
Le contenu de la base de données, au nom du type exemple_2017-03-30_11-41-38.sql.zip
Les fichiers spécifiques, au nom du type exemple_file_2017_03_30.zip
Etape 2 création d’un site WordPress « blanc » sur l’hébergement Infomaniak ;
2.1 Console d’administration
Accès à la console d’administration Infomaniak avec l’adresse mail et l’identifiant noté sur la check-list (dans les informations à conserver).
2.2 Créer un compte FTP dans l’hébergement infomaniak correspondant
Aller dans l’hébergement défini pour le site à transférer (Anne-Laure pour moi). Créer un utilisateur (accès à l’ensemble du répertoire ou un répertoire spécifique), dans l’onglet FTP/SSH, bouton « AJOUTER ».
Noter les informations suivantes dans la check- list (dans les informations à conserver, partie A) :
Serveur hôte
abcd.vps.infomaniak.com
Nom compte
abcd_exemple
Mot de passe
mot-de-passe2
2.3 Avec filezilla, transférer les fichiers dans le nouvel hébergement
Les fichiers zip de plus de 40 Mo doivent être uploadés avec filezilla et pas le gestionnaire de fichier en ligne d’infomaniak.
MAJ du 30/07/2018 : on peut aussi utiliser l’excellente extension gratuite Updraft Plus pour gérer les sauvegardes et transferts.
Dans Filezilla, on paramètre le compte comme dans cette copie d’écran, avec les informations notées lorsqu’on a créé le compte FTP de l’hébergement Infomaniak :
dans le compte FTP infomaniak, créer un répertoire ald-utils et y placer le fichier zippé des fichiers de l’ancien site (le répertoire wp-content, exemple_file_2017_03_30.zip). Ca prend du temps. En attendant, on peut créer le site wordpress.
2.4 Création du site WordPress Infomaniak ;
Dans le tableau de bord Infomaniak, cliquer sur le bouton « ajouter un site »
(en fait j’ai créé testal.com et pas test.com) Puis « enregistrer »
On arrive alors à une page « assistant de démarrage ». Cliquer sur « installer mon site wordPress » puis « installation avancée »
Puis installer
Noter l’identifiant WordPress et son mot de passe dans la check-list (partie B).
Nota si on avait déjà créé le site, mais pas installé WordPress, il suffit de cliquer sur le bouton « OFF » de la colonne WordPress pour le site concerné, directement dans l’écran Tableau de bord Infomaniak.
2.5 Créer une base de données à partir du tableau de bord Infomaniak
La base de données créées automatiquement par Infomaniak est malheureusement affublée d’un nom illisible, de type abcd_WP124026, et il n’est pas possible de modifier les informations textuelle pour spécifier à quel site se rapporte la base.
Je préfère donc créer une nouvelle base de données, avec un nom clair du type ‘abcd_testal’ que j’associe ensuite au site WordPress testal.com.
Pour cela, c’est l’onglet « bases de données » puis le bouton « ajouter une base de données ».
lui donner un nom intelligible, ici abcd_testal et activer « créer un nouvel utilisateur ».
Noter qu’on peut créer un mot de passe de bonne qualité simplement en cliquant sur le cadenas ouvert à droite de « mot de passe ». Le cadenas devient alors fermé et vert.
On note soigneusement les informations :
serveur hôte
abcd.myd.infomaniak.com
Nom de la base
abcd_testal
Nom compte
abcd_testal
Mot de passe
mot-de-passe3
Puis cliquer sur Enregistrer
2.6 paramétrage du site WordPress Infomaniak
Pour prévisualiser le site avant de faire le transfert de DNS, Infomaniak a une url de prévisualisation très bien faite.
Pour pouvoir voir et modifier ce site qui n’existe pas pour les internautes, il faut signifier au serveur Infomaniak d’utiliser le lien preview plutôt que l’url habituelle du site.
Aller dans Site Web / Mon Site WordPress. La liste des sites de l’hébergement s’affiche. Cliquer sur le bouton « Configurer » du site en cours de transfert.
On voit que l’adresse du site est http://testal.com, (et aussi que la base de données est celle créée par Infomaniak).
Cliquer sur le bouton « paramètres ».
Dans « site internet à utiliser », choisir l’adresse preview, de type ‘’ http://abcdgalg.preview.infomaniak.website puis « valider ».
Dans paramètres du site, sélectionner le site internet à utiliser en mode preview, et pas l’adresse normale du site.
Copier-coller l’adresse dans la check-list. On peut par exemple cliquer sur le nom de la base de données et copier le nom du site dans la table prefix_options, champ siteurl
2.7 Modifier la base de données nouvellement créée
https://h2-phpmyadmin.infomaniak.ch/MySQLAdmin/
ouvrir la base de données créée manuellement (pas celle créée par infomaniak)
Y importer la bdd du site d’origine (exemple_2017-03-30_11-41-38.sql.zip)
dans la table prefix_options, modifier :
siteurl site de prévisualisation http://abcdgalg.preview.infomaniak.website
home site de prévisualisation http://abcdgalg.preview.infomaniak.website
Copier le prefixe utilisé, par exemple Zzr4ez_, pour les tables et le coller dans la checklist (zone D).
2.8 Décompresser et déplacer les fichiers zippés avec le ftp infomaniak
MAJ du 30/07/2018 : on peut aussi utiliser l’excellente extension gratuite Updraft Plus pour gérer les sauvegardes et transferts.
ftp en ligne https://admin2.infomaniak.com/ftp/index.php?sServer=abcd.vps.infomaniak.com
Dans ald-utils, décompresser exemple_file_2017_03_30.zip.
Ensuite, déplacer les fichiers au bon endroit dans le répertoire wp-content du site en cours de transfert. Je laisse les extensions et thèmes installés automatiquement par infomaniak. Je supprime le sous-répertoire 2017 créé par infomaniak dans le répertoire uploads.
2.9 modifier wp-config
Avec le FTP en ligne Infomaniak éditer wp-config.php
Il contient
define('DB_NAME', DB_NAME');
/** MySQL database username */
define('DB_USER', 'DB_USER');
/** MySQL database password */
define('DB_PASSWORD', 'DB_PASSWORD');
/** MySQL hostname */
define('DB_HOST', 'DB_HOST');
et plus loin
$table_prefix = 'table_prefix';
Remplacer les contenus par les informations suivantes, notées dans la checklist (parties C et D) :
DB_NAME par le Nom de la base – abcd_testal
DB_USER par le Nom compte – abcd_testal
DB_PASSWORD par le Mot de passe – mot-de-passe3
DB_HOST par le serveur hôte – abcd.myd.infomaniak.com
et $table_prefix par le Préfixe de base de données – Zzr4ez_
Puis Enregistrer.
Maintenant, lorsqu’on visualise le site, on a le site initial.
2.10 Tester la vitesse du site avant transfert (optionnel)
On peut tester la vitesse des sites dans l’hébergement initial avant de le quitter. On peut utiliser les sites suivants et faire une copie d’écran pour conserver l’information.
On peut accéder au tableau de bord WordPress du futur site en suivant le lien de preview et en ajoutant wp-login à la fin. On se connecte avec les informations notées dans la partie B de la check-list.
Je réactive ces deux extensions (elles sont désactivées du fait du changement de base de données).
Etape 4 Pointage des DNS vers le nouvel hébergement
4.1 Pointer vers les bonnes adresses IP
Dans le tableau de bord Infomaniak, un bandeau indique que certains noms de domaines ne sont pas correctement liés à cet hébergement.
C’est normal puisqu’on n’a pas encore indiqué la nouvelle adresse IP de l’hébergement. Pour tous les internautes, l’url du site pointe toujours vers l’ancien hébergement.
Il suffit de cliquer sur « afficher les diagnostics » pour visualiser les recommandations d’Infomaniak :
testal.com
AAAA
2001:db8:0:85a3:0:0:ac1f:8001
testal.com
A
81.174.114.61
www. testal.com
CNAME
testal.com.
On peut suivre la propagation avec le tableau de bord Infomaniak ou whatsmydns.
4.2 Modifier l’URL du site
Comme dans le paragraphe 2.6 (paramétrage du site WordPress Infomaniak), on modifie le « site internet à utiliser » pour qu’il redevienne http://testal.com
Etape 5 Activation d’un certificat SSL Let’s Encrypt.
Installation d’un certificat SSL Let’s Encrypt
Cette action ne peut être réalisée que lorsque la propagation des nouveaux DNS est suffisante. Il y aura donc une période d’une durée variant entre quelques dizaines de minute et quelques heures (24 heures max) durant laquelle le site ne sera accessible qu’en http.
Dans le tableau de bord Infomaniak, choisir Certificats SSL dans le menu vertical à gauche.
Sélectionner le site pour lequel on veut un certificat puis cliquer sur « installer ».
Tant que les DNS ne sont pas suffisamment propagé (jusqu’au serveur Let’s Encrypt), on a un message d’erreur comme ci-dessous pour le certificat SSL gratuit :
Une fois que l’erreur a cessé, on sélectionne ce certificat et on l’installe.
Régler l’url utilisée pour le site (https)
Comme dans le paragraphe 2.6 (paramétrage du site WordPress Infomaniak), on modifie le « site internet à utiliser » pour qu’il redevienne https://testal.com . Cette option n’est proposée que lorsqu’on a installé un certificat SSL.
Autres réglages
Je n’ai pas eu besoin de modifier le .htaccess puisqu’Infomaniak gère tout seul.
Optionnel : mesurer la vitesse du site après transfert
Lorsque nous voulons réserver certains contenus d’un site WordPress à des personnes (ou groupes de personnes) spécifiques, il faut rendre certains contenus privés. Nous allons voir comment le faire avec trois extensions.
Chris Lema, une référence pour les extensions de « membership »
Chris Lema est un auteur prolifique, très connu dans le monde WordPress anglophone. Il a, entre autres, examiné une trentaine d’extensions de gestion des « memberships », qui permettent de créer des espaces réservés dans un site web. Et chacun des articles dédié à l’une de ces extensions est incroyablement complet et détaillé.
La source principale d’information pour cet article est ce billet, en anglais, de Chris Lema : Membership Plugin Review: Members. Mais vous pourrez aussi trouver les articles suivants utiles, si vous lisez l’anglais :
Choosing a WordPress Membership Plugin qui propose un logigramme pour déterminer quel est le meilleur choix d’extension de membership selon l’utilisation prévue.
Comparing WordPress Membership Plugins, qui propose le meilleur choix selon 6 critères (prix, facilité d’utilisation, possibilité de faire du contenu « goutte à goutte », interruption temporaire des inscriptions, …).
« Membership » ou « subscription » ?
Une extension de « membership » gérera toujours l’enregistrement d’utilisateur (moyennant paiement ou non) et la possibilité pour ces utilisateurs connectés de voir des contenus protégés.
Certaines gèreront également d’autres fonctionnalités utiles telles que :
gestion des renouvellement d’abonnement (payant ou pas) ;
créer une liste des abonnés ;
créer une page spéciale pour chaque abonné ;
associer des systèmes de paiement ;
gérer des évènements ;
…
Pour en savoir plus, on peut lire Don’t confuse Memberships and Subscriptions. Chris Lema y explique que les extensions de membership gère l’accès à des contenus. Mais l’inscription, ou le renouvellement d’un abonnement nécessite une extension de « subscription ».
Créer un espace réservé sur un site avec Members
Dans mon cas, je suis en phase d’expérimentation. Je privilégie donc le côté gratuit, ainsi que la possibilité de créer des extensions moi même pour étendre ses fonctions. J’ai donc choisi d’utiliser l’extension « Members », de Justin Tadlock. L’article de Chris Lema, Membership Plugin Review: Members, explique comment l’utiliser avec deux autres extensions pour créer des contenus réservés, gérer les login et mise à jour des profils des abonnés et enfin définir des menus pour les abonnés et les autres. C’est donc un excellent moyen de se familiariser avec la création d’un site à contenus réservés.
Je ne vais pas reprendre le contenu de l’article de Chris Lema de manière détaillée. J’ai réalisée les étapes telles qu’il les décrit.
étape 1, installer les trois extensions nécessaires
« Members » permettra d’attribuer des rôles aux utilisateurs du site puis de restreindre l’accès ou la modification de contenus (ou du site tout entier) selon les rôles.
« Nav Menu Roles » va permettre de définir quels menus sont vus par qui (quels rôles).
« Profile Builder » facilite la gestion des comptes des utilisateurs. L’extension permet d’avoir une page spécifique pour se connecter ou s’enregistrer (en évitant l’affreuse page wp-login.php de WordPress). Elle autorise également l’utilisateur à mettre à jour son profil et son mot de passe.
Etape 2, activer « Members » et la paramétrer
Après avoir activé « Members », je crée un rôle spécifique « membre-site ». En dessous du champs dans lequel je crée le nom de ce rôle, je vois écrit « Rôle : membresite« , que je peux modifier. C’est ce nom qui servira ensuite pour définir dans du code ou des shortcode des actions spécifiques à ce rôle. Dans « modifier les capacités », je laisse la seule case cochée : « read ». Les personnes aux rôles « membre-site » ne pourront que lire des contenus.
Etape 3, activer « Profile Builder » et la paramétrer
Les shortcode utilisables avec cette extension sont visibles dans le nouveau menu « Profile Builder » > « Informations de base ». D’autres shortcodes sont également listés dans la description de l’extension, sur WordPress.org.
Je crée les pages suivantes :
« accueil », qui sera réglée comme page d’accueil du site ;
« Connexion » contenant le short code [[wppb-login register_url= »http://exemple.com/page-enregistrement/ » lostpassword_url= »http://exemple.com/lost-password/ »] ] ;
« Enregistrement » avec le short code [[wppb-register role= »membresite »] ] ;
« votre profil » avec le short code [[wppb-edit-profile] ] ;
« renouvellement du mot de passe » avec le short code [[wppb-recover-password] ]
« contenu protégé », avec le contenu protégé, et par exemple des liens vers d’autres contenus protégés.
Attention, sur la page d’enregistrement, il faut préciser le rôle des personnes qui pourront s’enregistrer. On doit donc placer le short code [[wppb-register role= »desired_role »]], avec desired_role remplacé par le rôle correspondant.
La page « contenu protégé » est protégée en cliquant sur « membre-site » sous l’éditeur de la page. On peut également définir un message d’erreur qui sera affiché si une personne non connectée tente d’accéder à cette page. Si on veut un message d’erreur commun à toutes les pages dont le contenu est protégé, on la définit dans « Réglages » > « Members ».
Dans un widget de la barre latérale, on peut ajouter le widget « Profile Builder Login Widget » afin de permettre aux utilisateurs de se connecter, déconnecter, être redirigé sur les contenus protégés une fois connecté.
Etape 4, gestion des menus
La structure de menu doit permettre d’avoir des éléments affichés seulement pour les membres, d’autres pour tous.
Après activation de « Nav Menu Roles« , lorsqu’on va dans « Apparence » > « Menus », on peut choisir ce qui s’affiche selon les rôles.
Par exemple, pour l’élément « contenu protégé », on clique sur « utilisateurs connectés » et on choisit les rôles « membre-site » et « administrateur ».
Par contre, l’élément « login » doit être visible pour les utilisateurs non connectés seulement.
Et voilà, j’ai maintenant un site web avec du contenu protégé !
Exploration rapide des fonctionnalités
Profile Builder a d’autres fonctionnalités utiles :
Dans « Profile Builder » > « Paramètres généraux », on peut définir la Longueur minimale du Mot de Passe et surtout régler la Sûreté minimale du Mot de Passe. J’ai essayé avec 8 caractères minimum et une sureté minimale sur « moyen » ;
Dans « Profile Builder » > « Paramètres généraux », on peut cocher « Confirmation par e-mail » puis régler le contenu des emails expédiés ;
Dans « Profile Builder » > « Paramètres de la barre Administration », on peut (et on devrait) régler sur « masquer » pour tous les rôles qui ne sont pas administrateur ou éditeur.
Il est possible d’autoriser l’enregistrement en ligne via les réglages de WordPress (« Réglages » > « Général ») : il suffit de cocher « tout le monde peut s’enregistrer » et de définir le rôle par défaut des personnes qui s’enregistrent. Mais avec les extensions installées, il n’est pas possible de limiter les enregistrements à ceux qui sont autorisés par l’administrateur. Profile Builder propose de recourir à une extension payante pour celà.
Members a également d’autres fonctionnalités intéressantes :
On peut activer des widgets spécifiques dans la page « Réglages » > « Members », en cochant « Activer le widget du formulaire de connexion » et/ou « Activer le widget utilisateurs ». Le deuxième widget permet de voir la liste des autres utilisateurs qui ont le rôle défini dans le widget. Je préfère les widgets de Profile Builder.
on peut cocher « Activer site privé » : lorsque la case est cochée, c’est l’ensemble du site qui devient privé. Toute personne non connectée qui essaie de lire un contenu du site est automatiquement redirigée sur la page de connexion WordPress par défaut ;
on peut cocher « Désactiver le flux » : pour afficher un message d’erreur pour le flux RSS du site. Ça paraît essentiel en effet ;
Si on restreint l’accès à une page, toutes ses pages « enfant » ont par défaut le même réglage (cf cette question sur le forum themehybrid.com).
Avec un peu de code additionnel, on peut régler WordPress pour afficher les résumés à tous les internautes et restreindre l’accès au reste de l’article (ou de la page) : cf cette question et cette autre question sur le forum themehybrid.com ;
Autres extensions en complément
Si je veux faire payer l’accès au contenu réservé, je pourrai utiliser Membership & Content Restriction – Paid Member Subscriptions, qui fonctionne avec Profile Builder que j’utilise ici. Mais logiquement je peux utiliser n’importe quel autre extension de « souscription ».
Le gros avantage de Members est qu’il s’intègre très bien avec d’autres extensions, même si elles ne le disent pas explicitement. En effet, Members utilise des fonctions de WordPress pour créer les rôles. Par exemple Event espresso 4 permet aux différents rôles créés avec Members d’accéder aux contenus liés aux événements selon leurs rôles. Il est également possible d’utiliser Learndash avec Members, comme indiqué dans cette question sur le forum themehybrid.com.
L’extension gratuite MailChimp User Sync devrait permettre de synchroniser des listes MailChimp selon les rôles.
Et maintenant ?
Je vais créer un site à contenu privé pour explorer un peu plus ce qu’il est possible de faire.
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
Sauvegarder la base de données du site !
Commentaires récents