A force de voir des gens avoir des problèmes avec le module d’installation automatique de WordPress chez OVH, je suis allée tester moi-​​même pour voir tous les défauts de cette installation.

Résultat :

  • je comprends pourquoi ça ne marche pas
  • il y a moyen d’installer « presque » correctement WordPress automatiquement…
  • … mais ça n’en vaut pas vraiment la peine !

Pourquoi le module standard installe une mauvaise configuration de WordPress

Tout se joue au démarrage. L’accès se fait via le manager, dans la section hébergement. (Cliquez sur le copies d’écran pour les afficher en grand).

L’accès aux modules d’OVH se fait via le manager, dans l’onglet hébergement

Ce n’est pas pour craner, mais vous noterez que j’ai un hébergement premium (un 300GP exactement), donc censé être performant. Ce léger détail a son importance pour la suite.

On arrive ensuite sur la fenêtre de gestion des modules, il faut en ajouter un :

Cliquer ensuite sur ajouter module

Et là, première mauvaise surprise, la version de WordPress n’est pas vraiment à jour !

Choisir le module WordPress, argh 3.6

Eh oui, en juin 2014 OVH propose encore une version 3.6.1 qui date du 12 septembre 2013 ! On est est, aujourd’hui, exactement à trois versions majeures de plus.  A quand la prochaine montée de version ? C’est une fois par an, c’est ça ?

Voici donc l’écran de paramétrage par défaut, avec deux gros problèmes :

Paramétrages par défaut de l’installation WordPress automatique

Le premier problème : le répertoire d’installation, par défaut un « WordPress3 » qui va ensuite poser des problèmes. D’abord ce n’est pas une belle url, ensuite, on le verra, en l’absence d’accès à phpmyadmin, le déménagement n’est pas simple, enfin c’est un footprint.

Le répertoire « par défaut » du site sans sous répertoire est possible, mais la plupart des gens « font confiance à OVH » et choisissent le /​WordPress3

Il serait tellement simple de tester l’existence de fichiers autres que les fichiers par défaut d’OVH au niveau de la racine, et de proposer le « www » si rien n’a été installé.

Le deuxième problème, le plus grave : OVH nous propose une configuration par défaut pour la base de données qui serait la meilleure option possible.

Malheureusement, en activant le mode avancé, on voit que ce n’est pas le cas :

« La meilleure option possible » ?

Car c’est uniquement en cliquant sur les paramètres avancés — ce qu’aucun utilisateur novice ne fait jamais, faisant confiance à OVH — qu’on s’aperçoit qu’on est limité drastiquement en nombre de connexions simultanées et qu’on n’aura pas accès à la base de données via phpmyadmin.

Merci OVH ! Dans mon cas, j’aurais payé un hébergement premium avec sql privé pour avoir 10 connexions simultanées !

Là encore, au lieu de simplement parler de « meilleure option possible » (ce qui est purement du foutage de gueule, dans ce cas) il serait mieux de mettre cet avertissement sur l’écran précédent. « Vous serez limité à 10 connexions simultanées et n’aurez pas accès à phpmyadmin, si vous voulez choisir une autre option, cliquez sur le mode avancé« .

Non ?

L’installation est très rapide. Je vois le message sur mon écran, qui m’informe de l’arrivée d’un mail dans ma boite…

Confirmation de l’installation de WordPress

et là encore, hyper mauvaise surprise : l’utilisateur par défaut est … « admin ».

Mail de confirmation, argh utilisateur admin

Or c’est avec la 3.0 (7 février 2011) qu’il est possible de choisir un identifiant autre que « admin » lors de l’installation. Cela fait donc plus de trois ans qu’OVH fait pour les utilisateurs néophytes des installations non sécurisées, avec une version trop vieille, avec un mot de passe relativement faible, un des users les plus testés par les bots, et aucune protection contre les attaques en force brute, alors même qu’il a un script d’installation personnalisé.

Et que, cerise sur le gâteau, le dévérolage d’un site hacké, quand on n’a pas accès à phpmyadmin… « c’est pas simple ».

Le blog livré par OVH

Voilà donc l’écran d’accueil. On s’est connecté avec ce merveilleux utilisateur admin, et le mot de passe — moyennement sécurisé — généré lors de l’installation. Comme on est sur une vieille version, on n’a pas été incité à aller le modifier pour quelque chose de mieux dans le profil.

L’accueil une fois WordPress installé automatiquement

Le « titre » du blog n’a pas été rempli (normal), les modules installés ne sont pas à jour — normal. Mais ce qui me choque, c’est de voir, justement ce qui a été installé : deux plugins de cache, WP Super Cache et DB Cache Reloaded Fix.

Donc non seulement OVH bride mes connexion à la base de données, mais il pense en plus que j’ai besoin d’un cache ? Ca va la parano ?

Et c’est là qu’on rentre dans le gros du problème, celui qui génère plusieurs demandes d’aide par jour sur le forum de WordPress : WP Super Cache n’est pas complètement configuré, — et ce qui est configuré est mal fait ! Sans aucun message d’avertissement…

La configuration de WP Super Cache

En arrivant sur la page de réglages du plugin, on voit un certain nombre de choses qui clochent : en particulier la compression des pages n’est pas activée, ni le nettoyage des anciennes pages (« Garbage »). Mais surtout le plugin ne peut pas fonctionner sans mise à jour des règles de réécriture.

Les paramétrages par défaut du plugin de cache chez OVH

La configuration d’un plugin de cache est toujours « un peu complexe », en particulier pour les plugins à l’ancienne, comme WP Super Cache. Honnêtement, si vous avez besoin d’un tel plugin (donc si vous avez du trafic), je vous recommande WP Rocket, qui remplace avantageusement les deux plugins proposés par OVH.

Quoi qu’il en soit, vous avez WP Super Cache, et vous devez le désactiver (pas super simple non plus) ou travailler avec.

Pour travailler avec WP Super Cache, le principe va être :

  1. d’activer les permaliens, pour générer le fichier .htaccess dont WP Super Cache a besoin. (Le principe d’un plugin de cache étant de « renvoyer » l’internaute sur un fichier statique, au lieu de servir la page normale générée par WordPress, cela se fait via des redirections et des réécritures)
  2. Configurer de façon optimum WP Super Cache
  3. Et surtout, désactiver le cache pour les utilisateurs enregistrés, pour permettre à l’admin et aux auteurs de voir en direct l’impact de leurs modifications (qui est la cause d’angoisses et d’interrogations multiples au support, je le rappelle).

Pour activer les permaliens, cela se passe dans « Réglages, Permaliens » :

Activer les permaliens, avec une structure d’url courte

Je recommande la structure d’url la plus courte et la plus simple (%postname%). En enregistrant les modifications, on créé le fichier .htaccess

En retournant sur les réglages de plugin, on peut faire la mise à jour des règles de réécriture :

Les modifications apportées au fichier .htaccess par le module de cache

C’est tout ces éléments qui sont insérés dans le fichier .htaccess et qui devront être supprimés lors de la désactivation.

Il reste à corriger les autres paramétrages (donc activer la compression et empêcher le cache pour les utilisateurs connectés)

Accessoirement, WP Super Cache vous conseille d’utiliser JetPack. Pas moi…

Comment avoir une configuration sur laquelle on peut travailler

L’essentiel des problèmes (à part la configuration incomplète du plugin de cache) pourrait être évitée dès l’installation, en :

  • installant le blog dans le répertoire « par défaut » (www) sans le sous répertoire /​WordPress3/​
  • créant et utilisant une base de données standard

Il faut d’abord créer sa base de données, ce qui se fait à nouveau via le panel utilisateur :

Accès à la gestion des bases de données OVH

Attention à bien choisir « Gestion SQL » et pas « Phpmyadmin » (qui est l’interface que vous utiliserez APRES si vous avez besoin d’aller dans la base de données). (SQL privé est une option supplémentaire, activée uniquement si vous avez payé pour…)

Le panneau de gestion des bases de données, avec les bases existantes

On arrive alors sur le panneau de gestion. Dans mon cas, des bases existent déjà, je vous ai juste laissé la taille pour vous montrer qu’on peut héberger plusieurs blogs sur une seule base (il y en a une dizaine par base).

En cliquant sur le « Nouvelle Base » à gauche, avec l’icone de dauphin, vous allez être dirigé vers votre écran de création de base de données. (attention, ne prenez PAS une pas PostgresSQL ça ne marche pas avec WordPress).

Créer une base de données, en choisissant les bases incluses dans l’hébergement

Le « type de base » correspond au contrat. Normalement, vous n’avez que la possibilité de créer une base incluse (le chiffre entre parenthèses indique le nombre de base disponibles).

En validant vous arrivez sur cet écran :

Il reste à nommer la base de données

Le début du nom de la base de données est imposé par OVH. Vous rajoutez quelque chose après, facile à mémoriser (ça peut être « blog ») et vous validez. C’est tout. Vous recevrez ensuite par mail les identifiants de connexion à votre base de données (mot de passe et serveur essentiellement, l’utilisateur étant identique au nom de la base de données).

Et vous pouvez alors , dans l’écran d’installation du module, choisir une « base de données existante » (dont il faudra indiquer les paramètres).

Les corrections à apporter à l’installation de base

Quand vous avez déjà fait l’installation et travaillé sur le blog, c’est plus compliqué. Les points essentiels sont :

Passer sur une base de données standard au lieu de la « meilleure option possible »

Pour cela, il faut utiliser un plugin qui permet d’exporter la base de données à partir de l’admin WordPress, créer une base de données, importer la sauvegarde, et modifier le wp-config.php

Déménager le blog

Déménager le blog est une procédure courante. Elle permet de se débarrasser du /​WordPress3/​ dans l’url. Elle implique de corriger, dans la base de données, tous les liens avec les anciennes urls.

Changer l’utilisateur par défaut

C’est sans doute le plus simple. On crée un nouvel utilisateur « administrateur », on se reconnecte avec ce nouvel administrateur, et on supprime le premier « admin », en attribuant tous les posts au second.

Désactiver les plugins de cache

C’est bien caché dans la FAQ du plugin sur WordPress, il faut, pour désactiver WP Super Cache, modifier à la main deux fichiers, le fichier wp-config.php et le fameux .htaccess qu’on a vu au dessus.

Pour le fichier wp-config.php, il faut, via FTP, télécharger le fichier, l’ouvrir dans un éditeur (Notepad ++ est parfait), supprimer la ligne  define( 'WP_CACHE', true ); , enregistrer le fichier et le recharger via FTP.

La modification du fichier .htaccess va suivre le même principe. Mais… le fichier .htaccess a une extension qui n’est pas reconnue par Windows. La façon de le faire exactement dépend de votre logiciel FTP. Le principe est d’activer l’affichage des fichiers cachés, dans le logiciel FTP.

Téléchargez le fichier .htaccess, l’ouvrir dans Notepad++ .

Supprimer toutes les lignes entre « # BEGIN WPSuperCache » et « # END WPSuperCache » (y compris ces deux lignes), enregistrer le fichier, et le recharger sur le serveur.

Selon l’éditeur que vous utilisez, certains refusent d’enregistrer un fichier qui n’a pas une extension connue, et rajoutent un .txt

Dans ce cas, il faudra :

  1. télécharger le htaccess.txt sur le serveur
  2. supprimer manuellement le .htaccess existant
  3. renommer (clic droit de la souris) le fichier htaccess.txt en .htaccess (attention, le . devant le nom est essentiel)

L’autre méthode, plus brutale et tout aussi efficace, si vous n’avez pas fait d’autres modifications, est tout simplement de supprimer le fichier .htaccess via ftp, et de retourner dans l’admin du blog, enregistrer les permaliens.

Le plugin de cache de la base de données, lui, se désactive simplement.

Encore une fois, tant que vous avez un faible trafic, un cache est inutile. Avec un gros trafic, il y a de meilleurs plugins que ceux choisis par OVH.

… sans oublier de faire les mises à jour bien sûr…

Est-​​ce que ça en vaut la peine ?

Clairement, il faut absolument éviter l’installation via le module OVH. Sa « soi disant simplicité » va vous créer des tas de problèmes dont la résolution sera nettement plus difficile qu’une installation WordPress « normale », faite par vos soins, en téléchargeant une version à jour et en utilisant une base de données normale. Et c’est très énervant, car l’installation est « scriptée » (plugin rajoutés et activés), donc il aurait suffi d’un peu de boulot supplémentaire pour faire quelque chose de bien.

Si vous devez passer d’un « WordPress module » à un « WordPress normal », je peux vous le faire. J’en profiterai pour optimiser certains aspects du blog, en vous conseillant, notamment, sur les bons plugins.

Que pensez-vous de cet article ?
Super0
Bien0
Bof0
Nul0
Poster un commentaire