par Anne-Laure DELPECH | 30 Oct 2016 | Archives
J’hébergeais sur OVH un site assez simple, qui suit le bon fonctionnement de mes Raspberry Pi. Comme j’ai migré l’hébergement OVH sur un VPS OVH avec Plesk, j’ai également dû déplacer ce site.
J’explique donc ici comment installer un site composé de fichiers php et css dans un hébergement Plesk. Ce site n’a pas de base de données et n’utilise pas de gestionnaire de contenus type WordPress.
Créer un sous-domaine et y transférer les fichiers
J’ai ajouté un sous-domaine dans mon compte Plesk, par exemple domicile.mon-domaine.com.
J’y ai transféré les fichiers de l’hébergement initial en ftp. J’ai placé les fichiers dans un répertoire temporaire ‘temp-al’.
Placer les fichiers au bon endroit
Dans Plesk, tel qu’il est paramétré, les fichiers doivent être rangés comme suit :
- css dans le répertoire domicile.mon-domaine.com/css
- php ou html directement dans domicile.mon-domaine.com/
- favicon.ico à la racine (image 256x256px)
NOTA : mon VPS Plesk étant sous linux, les fichiers doivent tous être avec des fins de ligne en mode linux, et pas windows. Sinon ça ne fonctionne pas.
Donner l’accès au site
Lorsque le sous-domaine a été créé, Plesk y a placé un fichier index.html. Pour que ce soit index.php qui soit exécuté, il suffit de supprimer le fichier index.html.
Et maintenant, dans un navigateur, http://domicile.mon-domaine.com ouvre bien sur un site défini par le contenu de index.php.
Afficher les erreurs
En tant qu’administrateur, on peut modifier les paramètres PHP du sous-domaine et régler « display_error » sur « on ».
Et voilà !
par Anne-Laure DELPECH | 30 Oct 2016 | Archives
Nous allons voir ici comment se connecter en FTP à un hébergement Plesk, avec des outils comme net2ftp ou filezilla. La documentation Plesk (Accès FTP au site Web) est complète, j’indique juste ici quels sont les paramètres de connexion dans net2ftp ou Filezilla.
Utiliser net2ftp
Attention, il ne faut utiliser que des net2ftp sécurisés et fiables, comme ceux qui sont proposés par les hébergements OVH (ou aussi par un hébergement Plesk si on actionne le service).
Les identifiants et mots de passe FTP des hébergements Plesk sont définis comme indiqué dans ce document Plesk. Le serveur est simplement le nom de domaine concerné sans rien devant (domaine1.com par exemple)
Utiliser Filezilla
Voici le paramétrage (plesk-id et le mot de passe ont été définis dans comptes FTP du domaine mon-domaine.com) :
Et maintenant
On peut lire d’autres articles de cette série ici : Démarrer avec un hébergement VPS Plesk d’OVH
par Anne-Laure DELPECH | 30 Oct 2016 | Archives
Comme sur un hébergement OVH, il faut sauvegarder régulièrement les bases de données et les fichiers des sites hébergés. Avec un VPS équipé de « Plesk-resellers », il faut également sauvegarder les paramètres liés aux clients, abonnements, packs de service. Nous allons voir comment.
Sauvegarder tout ou partie des données Plesk
Cette partie n’est accessible qu’aux administrateurs du compte Plesk resellers.
Documentation Plesk : Sauvegarder et restaurer les données.
Dans « outils et utilitaires » > « Gestionnaire de sauvegardes », on peut définir les paramètres de sauvagarde, faire des sauvegardes unitaires ou des sauvegardes planifiées.
Qu’est-ce qui est sauvegardé ?
Selon la documentation Plesk Sauvegarder et restaurer les données :
| Contenu de la sauvegarde |
Données incluses |
| Configuration du revendeur |
- Paramètres personnels du revendeur
- Packs de services et abonnements
- Paramètres et configuration du compte client, sites, bases de données, boîtes mails, listes de diffusion
- Certificats SSL
- Informations sur les DNS
|
| Configuration et contenu du revendeur |
Toutes les options ci-dessus, plus :
- Contenu des sites Web
- Contenu des mails
- Contenu des listes de diffusion
- Contenu des bases de données
- Logs et statistiques
- Pages d’erreurs personnalisées
|
Définir les paramètres de sauvegarde
On peut définir un hébérgement OVH (pro ou perso) comme destination des sauvegardes.
Les paramètres sont définis comme suit (on obtient le nom d’hôte, le nom d’utilisateur FTP et son mot de passe dans le compte OVH de l’hébergement cible) :
Plesk : paramétrage du stockage FTP
Attention, la seule difficulté (que je n’ai résolue qu’après plusieurs échanges avec des techniciens OVH), est que Plesk doit pouvoir écrire sur la « racine » de la cible pour vérifier le bon fonctionnement avant de transférer la sauvegarde.
Donc le champ « répertoire » doit obligatoirement contenir quelque chose et le répertoire défini doit déjà exister dans le compte FTP cible.
Pour une sauvegarde unitaire :
Dans « stocker sous »,
- le stockage FTP proposé est celui qui a été défini dans les paramètres de sauvegarde.
- Je ne me souviens pas si j’ai défini le lieu de stockage du serveur.
Plesk : sauvegarder pour le « revendeur »
Planifier des sauvegardes
Voici les réglages que j’ai fait.
Plesk : planifier des sauvegardes
Sauvegarder le compte et les sites web (client)
Le client a accès à un menu « compte » dans lequel on trouve les boutons « Sauvegarder le compte et les sites Web » et « Sauvegarder les sites Web ».
Documentation Plesk : (Avancé) Sauvegarder et restaurer les sites Web
le fonctionnement est semblable à celui des sauvegardes de l’ensemble de Plesk.
Copier / cloner un site web (client)
Documentation Plesk : Utiliser un site provisoire.
Cette option « copier du site web » est accessible aux clients, selon les réglages de leur abonnement. Attention, cette option ne copie pas la base de données.
Lorsque le client clique sur « copie du site web », il peut choisir ses options :
Plesk : copie de site web
On peut utiliser cette fonction pour copier un site vers un autre (le cloner), mais cet autre est OBLIGATOIREMENT un élément du même domaine. Par exemple si je copie « knowledge.parcours-performance.com , je ne peux le copier que vers parcours-performance.com ou un de ses sous-domaines.
Et maintenant ?
Il reste à vérifier que je parviens à restaurer les données sauvagardées si nécessaire.
Cet article fait partie de la série Démarrer avec un hébergement VPS Plesk d’OVH.
par Anne-Laure DELPECH | 29 Oct 2016 | Archives
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.
Avec Plesk, on dispose du 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.
(2) utiliser toutes les fonctionnalités de Sucuri
J’utilise l’extension gratuite « Sucuri Security – Auditing, Malware Scanner and Hardening » pour la sécurité du site. Les modifications qui suivent sont réalisées avec cette extension.
- 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
(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.
par Anne-Laure DELPECH | 29 Oct 2016 | Archives
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.
Commentaires récents