Participant beaucoup au forum de support de WordPress en français, je suis souvent ammenée à répéter les mêmes recommandations. Autant en faire une check-list !
- Ton blog au validateur HTML passera
- Tes balises correctement fermera
- Ton article seul et ta home comparera
- Ton flux au validateur de flux soumettra
- Ton charset vérifiera
- Tes plugins désactivera
- Tes messages d’erreur analysera
- Ton codex lira
- Ton footer vérifiera
- Ton espace web et ta base de donnée ne confondra
Ton blog au validateur HTML passera
Si un code conforme aux recommandations du W3C n’est pas une absolue nécessité pour être bien positionné dans Google, c’est extrêmement utile pour débuguer un problème d’affichage (qui, la plupart du temps, provient d’un code non conforme).
J’utilise le validateur proposé dans les outils de l’extension Web Developper pour Firefox, qui est tout simplement celui du W3C, mais il y en a d’autres, notamment en français.
Les résultats sont clairs, ils listent tous les problèmes de compréhension de code par un navigateur. Il est possible de demander l’affichage du code, en dessous, et à ce moment là de voir ce qui se passe, pour corriger.
Une fois le code propre, on peut se concentrer sur les autres « vrais » problèmes (structure du CSS, erreurs de programmation etc.)
Tes balises correctement fermera
C’est la première erreur, la plus fréquente à faire, un moment d’inattention et hop ça y est, et ça génère des erreurs en cascade. C’est aussi la plus « économique » à corriger, une simple petite balise à rajouter, et hop, on peut se débarrasser d’une dizaine ou d’une centaine d’erreurs.
Pour savoir où se trouve le problème, il faut identifier la ligne où le validateur dit « opening tag was there », c’est généralement autour de cette ligne que le problème se trouve. Sinon, il reste à reprendre le code source de la page html et à péniblement vérifier à la main, en commençant par les balises les plus profondes.
Ton article seul et ta home comparera
C’est le moyen le plus rapide, quand quelque chose se décale brusquement dans la mise en forme, pour vérifier si le problème est lié à un article spécifique, et récent, (par exemple une balise more placée au mauvais endroit et empêchant la fermeture d’un élément), ou si il est lié aux éléments globaux du blog, essentiellement la sidebar, le header et le footer. Cela permet de circonscrire un peu les recherches.
Ton flux au validateur de flux soumettra
Les flux internes de WordPress sont assez solides, donc quand le flux est cassé, c’est généralement à cause du contenu d’un article. Le validateur de flux, aussi proposé par le W3C et présent dans l’extension Web developer permet d’identifier le texte juste avant le problème… et de remonter à l’article fautif, pour le corriger.
Ton charset vérifiera
Le charset, ou la convention de codage des caractères accentués (tous ceux que l’anglais, langue de naissance de l’internet et de l’informatique n’utilisent pas) détermine ils seront codés dans la base, dans les pages composant le thème wordpress, et donc comment ils apparaîtront au moment de l’affichage.
Donc s’il y a des caractères bizarres, c’est que quelque chose a changé.
Par défaut, WordPress est en utf-8, même en français. Mais cela peut être différent si :
- cela a été modifié cela dans les options du blog
- le blog a été commencé avec une vieille version, aux temps anciens que les moins de 20 ans ne peuvent pas connaître et où l’utf-8 n’était pas répandu
- pour une raison ou une autre le thème est dans un autre charset, cela peut être le cas d’un thème « adapté » à partir d’un autre outil, notamment Joomla
Dans ce cas là, il faut vérifier la cohérence des codages, et les remettre en phase.
Attention : simplement changer l’encodage (on dit l’interclassement dans ce cas) de votre base ne résoudra pas le problème, car les caractères sont codés en utf-8, il faudra en plus la convertir. La solution la plus simple reste la mise en conformité du thème.
Enfin, certaines fonctions php, comme strftime qui permet de renvoyer la date dans un format local, renvoient par défaut des caractères autres que l’utf-8, en l’occurence le charset correspondant aux variables locales. Si elles sont utilisées dans un thème utf-8, il faut en plus les convertir avec utf8_encode. C’est un point à vérifier quand les caractères bizarres sont limités à certains endroits gérés par un plugin (et c’est la fin de la minute geek).
Tes plugins désactivera
Quand tout ça ne donne rien, on passe à la vérification des plugins.
Un plugin à lui tout seul peut poser problème, ou une combinaison.
On commencera donc par désactiver les deux ou trois derniers plugins, puis, si cela ne donne rien, tous les plugins, en réactivant ensuite un par un. (Si le problème persiste quand tous les plugins sont désactivés, on peut sauter cette étape, et tout réactiver d’un coup).
Tes messages d’erreur analysera
Php affiche des messages d’erreurs assez explicites, ou en tout cas assez spécifiques, indiquant dans quel fichier se trouve l’instruction qu’il ne peut pas traiter.
Cela permet de voir facilement certaines erreurs (oubli du $ devant les noms de variables, du ; à la fin de la ligne d’instruction, ou problèmes dans les chaînes de caractères, par exemple une apostrophe qui n’est pas correctement échappée et qui termine un texte à afficher prématurément).
Cela donne aussi une petite idée du coupable, plugin, fonction native, fichier de modèle…
Ton codex lira
Le codex, partiellement traduit par l’équipe de WordPress-fr, donne une documentation précise, à la fois sur la logique globale de Wordpress, des guides sur l’installation, ou d’autres procédures et une documentation détaillée sur les options des fonctions.
Lire quelques grandes sections, comme les marqueurs de modèle ou la boucle permet au moins d’avoir une idée de ce que WordPress peut faire.
Ton footer vérifiera
Les thèmes peuvent parfois avoir des fonctions cachées dans leurs footers, soit honnêtes, simplement de l’encryptage java pour éviter qu’on enlève le lien retour, soit moins agréables, iframes ou autres.
Il suffit que le site sur lequel ces fonctions pointent soit inaccessibles pour qu’une erreur apparaisse.
En règle générale, ne pas prendre de thème dont on ne comprend pas une partie du code.
Ton espace web et ta base de donnée ne confondra
Il y a besoin de deux choses pour faire fonctionner WordPress : un espace Web, chez un hébergeur, où on place les fichiers contenus dans le zip. Il faut pour y accéder :
- une adresse ftp
- un nom d’utilisateur
- un mot de passe
La deuxième chose, c’est une base de données, MySQL, où vont être stockés toutes les options, les messages, les commentaires, les utilisateurs.
Elle se trouve « ailleurs », sur un serveur de base de données. La plupart du temps, celui-ci doit être créé, à la demande, il est aussi possible qu’une base soit créée par défaut, selon les hébergeurs.
Il faut pour que WordPress y accède :
- l’adresse du serveur, ou host. Cela peut être « localhost » (de moins en moins souvent), cela peut être autre chose, cela dépend des hébergeurs
- un nom d’utilisateur
- un mot de passe
Et ce ne sont pas les mêmes que pour l’espace FTP.
A priori, pour les connaître, il faut se rendre dans l’onglet concernant la gestion des bases de données chez son hébergeur, et cela apparaitra dans les détails de la base. Si il n’y a pas d’onglet… il y a de fortes chance pour que l’hébergement n’ait pas de base !
Et après, si rien ne marche ?
Cela résout déjà pas mal de problèmes. Mais il reste une communauté très active pour vous aider : le forum de support de WordPress en français, www.wordpress-fr.net.
Article très intéressant