Je n’ai plus de VPS Plesk depuis un bout de temps. Je laisse cet article en ligne pour information mais je ne pourrai pas répondre aux questions éventuelles.
Nous avons déjà vu comment transformer un site http en site https dans l’article migration d’un site WordPress en http vers https (SSL). Ici nous allons voir comment faire dans un hébergement Plesk VPS Classic de chez OVH. Il y a de petites différences avec un site d’un hébergement mutualisé OVH.
L’intérêt de passer en https
J’invite tous les anglophones à lire attentivement cet article de Wired. Il explique bien pourquoi tous les propriétaires de site devraient immédiatement chercher à passer leurs sites en https. Mais il va plus loin en montrant l’importance de l’interface utilisateur pour que les internautes comprennent les risques pris lorsqu’ils intéragissent avec un site non crypté. Le témoignage de l’Iranien est particulièrement édifiant.
La documentation de Plesk est incomplète sur ce sujet, mais le processus est très simple.
Il suffit de cliquer sur le lien « Let’s Encrypt » :
Pour les réglages, je coche « inclure www.domaine.com » même si je redirige www sur la version sans préfixe (attention ça n’est pas coché dans la copie d’écran ci-dessous mais il faut le faire) :
Une fois qu’on a cliqué sur « installer », on a au bout de quelques secondes un message en vert disant que le certificat est installé.
le contenu à ajouter dans .htaccess fonctionne aussi dans Plesk.
Et maintenant ?
Il faut vérifier que les redirections fonctionnent correctement. Un internaute doit pouvoir taper les url suivantes et être dirigé vers le site https://mon-domaine.com :
www.mon-domaine.com
mon-domaine.com
http://mon-domaine.com
mon-domaine.com/wp-login.php (ou wp-admin.php)
Une fois ces vérifications faites, ça y est, on a un site moderne et sécurisé.
A la création d’un site, il est indispensable de vérifier la sécurité et l’indexabilité du site WordPress. C’est également indispensable après le transfert d’un site vers un nouvel hébergement. Cette check_list contient des éléments applicables à tout site WordPress et des actions spécifiques au transfert vers un hébergement d’un VPS Plesk. Cet article fait partie de la série Démarrer avec un hébergement VPS Plesk d’OVH.
Vérification de la sécurité
(1) sécuriser tout ce qui peut l’être avec WordPress Toolkit.
Sécuriser un site avec le WordPress Toolkit de Plesk
Après avoir cliqué sur « analyser la sécurité », je donne l’autorisation de sécuriser tout ce qui ne l’est pas.
Nota : selon cet article sur Devblog.Plesk, les changements ne sont pas faits en modifiant .htaccess (et n’en lit même pas le contenu pour définir le statut de sécurité). C’est la configuration du serveur web qui est modifiée. Toute modification du .htaccess va remplacer la configuration serveur correspondante.
Exécuter tous les « hardening » proposés sauf « website firewall protection » (pas dans la version gratuite de sucuri) et « error logs » qui « can not be determined ». Attention, je n’ai jamais essayé de voir si Sucuri peut changer correctement le préfixe de base de données. J’ai procédé comme indiqué dans l’article Changer le préfixe de base de données WordPress.
Dans Settings / Général (ou par une console d’erreur comme Query Monitor), j’ai eu une erreur indiquant que Sucuri n’a plus l’autorisation de stocker les données de Sucuri dans /home/parcoursz/www/wp-content/uploads/sucuri. Au final pour corriger le problème, il suffit de désactiver Sucuri, supprimer les fichiers stockés dans wp-content/uploads/sucuri puis réactiver Sucuri.
(3) Modifier wp-config.php
Vérifier que Sucuri a ajouté define( ‘DISALLOW_FILE_EDIT’, true ); pour interdire la modification de fichiers à partir du tableau de bord WordPress ;
En profiter pour ajouter une instruction pour limiter le nombre de versions stockées pour un article ou une page : define( ‘WP_POST_REVISIONS’, 5 );
(4) Ajuster .hataccess
Normalement c’est inutile pour un site monosite. Pour un site multisite, il faudra l’ajuster, mais ce sera l’objet d’un autre article.
Vérification pour le SEO
Après la création d’un site ou son transfert, il faut vérifier quelques points essentiels pour que le site reste correctement indexé par les moteurs de recherche :
(5) Google analytics
Vérifier que l’identifiant google analytics du site est toujours correctement défini. Pour moi c’est dans le menu « Insight » puisque j’utilise l’extension « Google Analytics par MonsterInsights«
Vérifier que Google Analytics et Google for Webmasters nous considèrent toujours comme propriétaire du site : j’ai laissé un enregistrement TXT contenant un code de vérification Google dans les enregistrements DNS sur OVH (cf l’article Réglages DNS d’un hébergement tiers à domaines gérés par OVH). En principe il n’y a pas de problème mais il vaut mieux vérifier car on peut avoir oublié de transférer un fichier html de vérification ou ne pas avoir défini l’enregistrement TXT.
(6) Yoast SEO
Vérifier que les réglages de l’extension sont correctement faits ;
Vérifier que la connexion à la search console est faite correctement ;
Si les sitemaps dans google for webmasters ne sont pas récents, les soumettre à nouveau ;
Dans Google for Webmasters, regarder les erreurs d’exploration et les corriger (redirection) ;
Dans un site nouvellement créé, on vérifiera aussi que l’on a correctement rempli les extraits SEO pour l’ensemble des contenus.
(7) vitesse du site
Tester le site avec Google Test My Site puis corriger les défauts éventuels. Ce site teste l’ergonomie sur appareil mobile, la vitesse sur mobile et la vitesse sur ordinateur.
Avec WordPress, une bonne pratique de sécurité est d’utiliser un préfixe de base de données différent du préfixe par défaut. Celà complique en effet la tâche d’éventuels pirates.
Le préfixe par défaut de WordPress est « wp_ ». On peut le changer lors de l’installation de WordPress ou plus tard. Nous allons voir dans cet article comment changer le préfixe d’un site existant.
Attention, ce changement nécessite une bonne compréhension du fonctionnement d’une base de données pour WordPress. On peut casser un site internet si on le fait mal.
Il faut sauvegarder la base de données avant tout changement.
Ce tutoriel s’applique aux installation WordPress classiques. Pour une installation multisite, suivre les instructions de cet article de WPmuDev.
Changer le préfixe des tables
Quel préfixe choisir ?
L’idéal est d’utiliser 6 à 10 caractères composés de lettres minuscules ou majuscules et de chiffres, tel que p7fQ25Hg_ ou i9s5c0Fu1P_. Pour le créer, l’idéal est d’utiliser lastpass password generator, en n’oubliant pas d’ajouter « _ » à la fin du préfixe généré.
Avec phpMyAdmin :
Sauvegarder la base de données ;
Remplacer le préfixe de table : en sélectionnant toutes les tables (tout cocher) puis « remplacer le préfixe de table ».
WordPress : changer le préfixe de base de données (2)
Et voilà, le préfixe des tables de notre base de données est devenu « newprefix_ ». A ce stade, notre site ne fonctionne plus du tout ! En effet, on n’a pas encore « dit » à WordPress que le préfixe de tables a changé.
Modifier wp-config.php
On édite wp-config.php pour que la ligne :
$table_prefix = 'wp_';
devienne
$table_prefix = 'newprefix_';
Après enregistrement du fichier modifié, les internautes peuvent de nouveau accéder au site. Mais l’accès au tableau de bord reste bloqué.
Changer le préfixe de certains contenus des tables
Le préfixe de table est également utilisé à l’intérieur de certaines tables. C’est le cas de certains contenus du champ option_name de la table « newprefix_options », et du champ meta_key dans la table « newprefix_usermeta ».
Modifier les « option_name » avec l’ancien préfixe
La commande SQL pour afficher les lignes concernées, de la table « newprefix_options » est :
SELECT * FROM `newprefix_options` WHERE `option_name` LIKE '%wp_%'
On peut aussi le faire dans l’interface graphique de phpMyAdmin.
On obtient une liste d’éléments de la table qui contiennent wp_. Mais attention, bon nombre de lignes ne doivent pas être modifiées. Pour le site dont je réalise la modification en écrivant ce tutoriel, j’ai obtenu 78 lignes dans lesquelles ‘option_name’ est « LIKE » ‘wp_’. En fait, la seule à modifier (à la main) est wp_user_roles qui devient newprefix_user_roles .
Modifier les meta_key avec l’ancien préfixe
La commande SQL pour afficher les lignes concernées, de la table « newprefix_usermeta » est :
SELECT * FROM `newprefix_usermeta` WHERE `meta_key` LIKE '%wp_%'
Pour s’y retrouver, on ordonne la colonne « meta_key » puis on modifie, à la main, toutes les entrées pour lesquelles la valeur de « meta_key » commence par wp_. En général on trouve les valeurs suivantes, autant de fois qu’il y a d’utilisateurs enregistrés pour le site :
wp_capabilities
wp_dashboard_quick_press_last_post_id
wp_media_library_mode
wp_user-settings
wp_user-settings-time
wp_user_level
A ce stade, on vérifie que tout va bien en se connectant au tableau de bord du site modifié. Si tout va bien, on arrive à se connecter et on a terminé.
En cas de problèmes
Cet article de WPmuDev, donne quelques pistes si on observe des dysfonctionnements après le changement de préfixe.
Problème n° 1 : pas d’accès au site
Lorsqu’on met l’adresse du site dans un navigateur, on arrive à un écran nous proposant d’installer WordPress !
La solution est de modifier wp-config.php pour que la ligne $table_prefix = ‘newprefix_’; contienne la bonne valeur du nouveau préfixe.
Problème n°2 : les utilisateurs n’ont plus la permission de se connecter au site
Dans ce cas, on a omis de modifier une ou plusieurs entrées de la table « newprefix_usermeta » et certaines valeurs de « meta_key » contiennent toujours le préfixe « wp_ ». Il faut donc vérifier ce que l’on a fait.
Notre problème n’est pas résolu ?
Voir l’article How to Fix “Error Establishing Database Connection” for WordPress. Il arrive en particulier que des extensions mal codées utilisent uniquement le préfixe par défaut « wp_ ». Dans ce cas, elles ne peuvent plus fonctionner une fois le préfixe changé. Pour les identifier, on désactive toutes les extensions puis on les réactive une à une jusqu’à ce que le site casse. Une fois l’extension problématique identifiée, on la supprime. On peut aussi revenir à la copie de la base de données réalisée avant le changement.
Le fichier wp-config.php dit à WordPress quels sont ses principaux réglages lorsqu’il démarre. Les éléments minimaux sont : la manière d’accéder à la base de données et le chemin d’accès au répertoire contenant WordPress. Mais d’autres éléments sont utiles ou indispensables. (suite…)
Commentaires récents