Vivre du Web

Quand WordPress n’en fait qu’à sa tête !

8 juin 2006

Suite à une discussion sur le forum de WordPress France, j’ai découvert que je n’étais pas la seule à m’arracher les cheveux avec l’éditeur de texte de WordPress, en particulier, lorsque celui-ci modifie à volonté le positionnement des balises <p>.

Et oui, lorsque l’on écrit un article, on a une idée assez précise de l’endroit où l’on veut changer de paragraphe ou aller à la ligne. Et on n’est pas franchement d’accord si WordPress vient mettre son grain de sable là-dedans et nous casse notre belle mise en page. Or c’est ce qui arrive lors d’une sauvegarde sur deux.

Et en fait, il faut dire que le problème vient du fait que l’éditeur de texte nous induit en erreur.

En effet, l’éditeur de texte tinyMCE propose un bouton "html" qui affiche le code html de la page. Là, voyant que des balises <br />se sont intercalées au milieu de balises <p>, on s’attarde bien méticuleusement à modifier tout ça pour remettre de l’ordre dans nos paragraphes. C’est alors que oh! (mauvaise) surprise, au prochain enregistrement, de nouveau, tout est de travers ! Cela doit rappeler des choses à plus d’un utilisateur de WordPress.

Or, comme je le disais, c’est bien l’éditeur de texte qui nous induit en erreur. Et oui, car ces balises <p>, en fait, n’existe pas pour WordPress. Je m’explique.

Voici à quoi ressemble en général un article que l’on écrit dans l’éditeur de texte :

On voit un texte découpé en paragraphes bien ordonnés. Mais très souvent à la seconde sauvegarde, les sauts de ligne disparaissent. Alors, on a recours au bouton "HTML". Qui nous donne quelque chose comme ça :

C’est là que l’on voit les balises <p> qui structurent le texte avec les paragraphes. Mais si on va voir dans la base de données de WordPress, on voit ceci :

Plus aucune balise <p>, ni <br /> !

Seulement des sauts de ligne.

Après une petite recherche sur Internet, j’ai trouvé cet article qui décrit exactement le fonctionnement de WordPress :

WordPress by default uses a filter called wpautop to format posts. If you have a double line feed in a post, it will insert a paragraph tag (<p>) automatically as the post is rendered for the user. Single line feeds will optionally insert <br /> tags as well for an HTML line break. This way authors don’t have to worry about inserting HTML tags for paragraphs and line breaks while they are writing up a post. The posts are stored in the database raw (i.e. just the linefeeds and line breaks) - wpautop is run and the tags are inserted when the post is displayed.

Ce qui confirme ce que je pensais. Et qui explique comment fonctionne WordPress : c’est donc la fonction wpautop qui reformate l’article après coup en fonction des sauts de ligne.

Voila, pourquoi, il est finalement inutile de perdre trop de temps à peaufiner l’emplacement des balises <p>. Il faut surtout s’assurer que les sauts de ligne sont aux bons endroits.

Une autre solution consiste à mettre une classe, ou un style dans la balise <p> : <p class="info">texte</p>. Dans ce cas-là, comme je le soulignais dans la discussion sur le forum, les balises html sont conservées dans la base de données. Mais il faut dire que cette méthode est tout de même relativement fastidieuse.

Personnellement, la solution que j’utilise jusqu’à maintenant, est tout simplement de désactiver l’éditeur visuel de texte. J’ai remarqué que la mise en page des articles est bien plus stable d’une sauvegarde à l’autre.

Mais ce qui est plus intéressant, c’est que cet article m’a permis de découvrir aujourd’hui le plugin Xinha pour WordPress qui m’a l’air très prometteur :

Xinha is more advanced as an editor and handles all the HTML generation on the fly. When you hit return in Xinha, a paragraph <p> tag is inserted automatically and a new paragraph is started. Shift-return will cause a simple line break with a <br /> tag automatically. So where normal WordPress posts insert the line spacing tags when a post is displayed - Xinha inserts them on the fly when the post is written (and thus the <p> and <br /> tags are saved to the database record for the post)

Il ne me reste plus qu’à tester ce plugin qui aux dernière nouvelles fonctionnerait aussi pour WordPress 2. Je vous tiendrais au courant dans un prochain article.

technorati tags: wordpress, Xinha4WP

Article dans : WordPress