Convertir des romans en blog WordPress

Mon tout premier contrat pour Ancadweb n’est pas vraiment le genre de projet auquel ma formation de développeur m’aurait préparé (où j’avais à peu près fait de tout… sauf du blog WordPress).
Il s’agissait de développer un site diffusant une saga littéraire, ses chapitres transformés en articles enrichis de tout ce que le web peut apporter (images, décoration du texte, changements de polices en fonction des différents points de vue, infobulles présentant les différents personnages, téléchargement de versions imprimables des chapitres, pages détaillant l’histoire de l’univers évoqué, etc.), occasion aussi pour moi de me mettre à Divi, un des modèles WordPress les plus flexibles et populaires (offrant à peu près les mêmes possibilités qu’Elementor si assez différent dans son interface, pour ceux qui ne connaîtraient pas).
Me disant que rien n’est plus simple que de mettre en ligne du texte sur un système à l’origine développé pour les blogs, ou de l’enrichir sur un modèle prévu pour, j’avais d’ailleurs je dois dire largement sous-estimé le temps que me prendrait cette tâche (finissant par consacrer plus de trois semaines à un projet que j’aurais vu achevé au bout d’une).

Classer les chapitres autrement que par date

Ne serait-ce que présenter des chapitres dans le bon ordre, alors que WordPress, prévu pour des blogs, ne propose par défaut que de baser celui ci sur des dates, ne se fait pas sans aller toucher aux function.php du modèle (en passant par la création d’un thème enfant).

Si c’est une manipulation assez simple et qu’il suffit de copier d’un des nombreux sites consacrés à WordPress qui la présentent, elle n’est pas sans receler quelques pièges, notamment quand comme moi on souhaite baser l’ordre d’articles sur un champ personnalisé.
Si Divi permet facilement d’en ajouter, j’ai fini par me compte que pour qu’ils soient correctement pris en compte au niveau du classement les articles mieux valait les renseigner au niveau du php, sans quoi la méthode de classement semblait ignorée une fois sur deux (précisément si j’ouvrais le sommaire directement plutôt qu’à partir d’un article) et revenait alors à celui par défaut, par date inversée.

Là encore un morceau de code tout simple mais qu’il vaut mieux connaître.

En plus de quoi, comme entre temps la page listant les articles avait été mise en cache (et évidemment avec le mauvais ordre), j’ai dù passer une bonne journée à essayer de comprendre pourquoi même avec cette résolution de problème ils continuaient à tenir à se remettre par date.
Mon hébergeur dans sa grande mansuétude installant d’office une extension ‘super cache’ avec WordPress, en plus de la mise en cache déjà proposée par défaut, c’était d’autant moins évident que j’avais bien purgé celui de WordPress après ce changement. C’est celui propre à l’extension qui continuait à stocker et me faire revenir à une page obsolète.

Et pour ajouter à tout ça, à copier bêtement la méthode de classement des posts, j’avais oublié qu’elle comportait une condition, n’appliquant son résultat qu’aux listes d’articles par catégories, qui ne sont qu’une des nombreuses manières proposées par WordPress d’en obtenir une, d’autres pouvant l’être par étiquette, suite à une consultation des archives ou d’une recherche par exemple. Quelque chose de très simple à fixer une fois l’origine du problème réalisée, mais moins alors que les étapes précédentes me faisaient plutôt suspecter un nouveau problème de cache ou de non prise en compte de la variable.

Le travail des textes

Pensant WordPress capable de correctement digérer des textes venus d’un traitement de texte aussi commun que Microsoft Word (ce que me semblait indiquer qu’il en respecte la présentation) je les avais en effet directement copiés des fichiers .doc qui m’avaient été fournis à l’éditeur visuel de Divi.
Évidemment c’était en fait une des pires idées imaginables. La manière dont est respectée cette présentation revenant en fait pour WordPress/Divi à ajouter, même pas à chaque paragraphe mais à chaque retour à la ligne une balise <span> où sont renseignées toutes les données venues de Word et même si elles ne changent pas (dont par exemple le type et taille en pixels de la police utilisée, ce qui interdit de la rendre responsive sauf à aller éditer ces spans systématiquement pour leur ajouter des classes, et plus généralement empêche tout changement global fait à partir de l’interface de Divi de prendre effet).
Au final je n’ai pas trouvé mieux que d’effacer ces premières copies, aller repasser tous les chapitres en texte brut, les éditer comme html dans Visual Studio CodeBien plus pratique pour voir ce qu'on fait que l'onglet texte de l'éditeur de Divi, lequel n'a pas de coloration syntaxique. pour y inclure les balises de paragraphes ou span réellement nécessaires pour les changements de polices prévus (associées à des classes css renseignées comme CSS personnalisé dans Divi pour qu’elles puissent être adaptées aux différentes tailles d’écran), puis copier le tout dans l’onglet « texte » et surtout pas l’éditeur visuel (voir plus loin), et enfin d’aller remettre à la main tout ce qu’il était prévu de mettre en gras, italique ou dans une couleur différente (seules choses qui soient raisonnables de faire avec l’éditeur visuel).

Les subtilités de l’éditeur de Divi

Car en parlant de l’éditeur de Divi et de son interface, si à l’usage elle n’est pas si mal, elle est tout sauf très intuitive au premier abord, présentant pas moins de 3 manières d’éditer un texte, chacune fonctionnant différemment.
D’une part on a l’éditeur visuel (qui occupe au départ tout l’écran), où on peut évidemment créer et remplir des blocs de texte (et bien d’autres), et aussi en sélectionnant une partie d’un texte (ou une image) et en cliquant droit on se voit offrir l’option d’en changer le style (ce qui revient à créer une balise span correspondante). Piège ! Si un type ou une taille de police est changé par ce biais, cela donne exactement le même résultat que la copie depuis Word : une taille fixe venant des réglages par défaut de WordPress se retrouve incluse dans les attributs du span, interdisant de l’adapter aux différentes tailles d’écran (sauf en allant créer une version différente de page pour chaque appareil, une solution terriblement lourde par rapport à de simples réglages css).
D’autre part, si on active « modifier la publication », puis clique sur un petit engrenage en haut de l’espace où est représenté l’article, dont l’apparition supposée se déclencher au survol semble étrangement aléatoire (heureusement il existe aussi un menu des calques permettant d’y accéder) on peut ouvrir une fenêtre « texte paramètres », qui comme son nom ne l’indique pas permet aussi de le renseigner via son onglet « contenu » et s’avère -un peu- moins piégée que l’éditeur visuel).
Cet onglet « contenu » est lui même divisé en deux autres,  une partie « illustration » qui présente le texte mis en forme et est l’endroit où lui ajouter des images, et une partie « texte » qui le montre en texte brut avec la plupart (voir plus loin) des balises html utilisées (et est donc l’endroit où copier un texte déjà converti en html comme je l’avais fait).

… et de ses 3 fenêtres permettant d’éditer un texte

Ces trois possibilités conduisent à toutes sortes de subtilités qu’il vaut mieux connaître.

Par exemple si vous placez une image à partir de l’onglet illustration, elle sera enregistrée avec une classe css alignleft, aligncenter ou alignright, selon ce que vous sélectionnez (éditer le css de cette classe étant la meilleure manière de spécifier des marges adaptées à chaque placement sauf que…). En revanche si vous modifiez l’alignement d’une image via l’éditeur visuel, elle ne sera pas modifiée, juste la position de l’image en ajoutant un « float;left » (par exemple) à sa balise. Le résultat étant que si vous aviez prévu des marges pour vos images selon leur position, elles ne s’appliqueront pas aux images déplacées ainsi (qui continueront par exemple à appliquer celles prévues pour une image alignée à droite, si c’est ainsi qu’elles avaient été entrées à l’origine).

Par ailleurs, l’onglet illustration se différencie aussi de l’éditeur visuel en ce qu’il traite les images comme des caractères. Si vous placez votre curseur juste avant l’une d’elle, un simple backspace suffit à l’effacer. Il est donc bien plus sûr d’utiliser l’éditeur visuel si vous souhaitez faire remonter un texte par rapport à une image en effaçant des sauts de lignes sans risquer de l’effacer, par exemple.
Et pour finir avec l’onglet illustration, il a aussi pour particularité une interface quelque peu pénible : alors qu’il fait apparaître une barre de boutons en haut pour ajouter les images ou styler le texte à ce niveau, les développeurs de Divi ont fait le choix étrange de la faire défiler avec celui ci plutôt que de la rendre fixe (et le tout alors que cette fenêtre d’édition apparaît en plus par défaut comme une étroite bande sur la gauche de l’écran, si on peut heureusement l’élargir).

En d’autres termes, pour par exemple placer une image au milieu d’un long article, vous devez positionner votre curseur au bon endroit, puis remonter les x hauteurs d’écran de texte vous séparant des boutons, pour aller enfin cliquer sur « Ajouter Média » (et pour ceux qui se demanderaient, non la liste des raccourcis clavier de Divi n’en propose étrangement pas pour ça).

Pour compliquer encore les choses, le même bouton « Ajouter Média » est également présent sous l’onglet Texte mais y fonctionne différemment : au lieu de retenir la position du curseur et de placer le code de l’image demandée à l’endroit voulu comme on pourrait s’y attendre, celui ci le place systématiquement tout au bout du texte, nécessitant d’aller le copier coller pour les remettre au bon endroit. Ce qui est d’autant plus triste que là par contre ils avaient prévu de ne pas faire défiler le bouton avec le texte.

Et ce n’est pas la seule particularité désagréable du module « Texte » : alors qu’on pourrait croire qu’il représente le code html de la page ce qu’il en montre est en fait une forme bâtarde ajustée par Divi à chaque enregistrement, qui est susceptible d’effacer certains ajouts manuels au html pour peu que vous ayez utilisé l’un des autres modes d’édition entre temps.
Pour prendre une de mes mésaventures en exemple, quelque chose qui m’avait été demandé était d’ajouter une indentation à chaque retour à la ligne, même à l’intérieur d’un paragraphe.
Comme la propriété css :each-line permettant de faire cela n’est actuellement supportée que par un petit nombre de navigateurs, c’est quelque chose que j’avais fait au niveau du html pour les autres navigateurs en remplaçant tous les <br /> (balises de retour chariot) par « <br />&emsp; » (retour chariot suivi de quatre espaces insécables blancs), dans mes textes tels que transmis à WordPress. Et dans un premier temps cela semblait parfaitement fonctionner.
Seulement voilà, sans doute pour rendre le texte plus lisible par ses utilisateurs les plus novices, Divi préfère ne pas montrer les <br /> même dans l’onglet supposé nous montrer les balises html, et, quand on enregistre après des modifications faites dans une autre partie de l’éditeur, décide plutôt d’interpréter/exécuter celles ci sans qu’on lui ai rien demandé, les remplaçant par des retours à la ligne visibles sans plus de <br /> qui apparaisse.
En prime, quand on modifie les textes via l’éditeur visuel, ce qui n’a été entré qu’au niveau du html (comme mes &emsp;) ne semble pas pris en compte, et est susceptible de disparaître carrément à l’enregistrement.
Ces deux choses combinées faisant que quelques modifications avec l’éditeur visuel plus tard je me suis retrouvé non seulement avec une disparition de tous les retraits prévus après sauts de lignes, mais avec l’impossibilité même de les remettre en utilisant la même méthode via l’éditeur « texte » de Divi, le code tel qu’il me le présentait ne contenant plus aucune balise <br /> à remplacer.
La seule option pour résoudre ce problème (à part peut être aller manuellement ajouter les espaces au début de chaque ligne dans l’éditeur visuel, je ne sais combien de centaines de fois à l’échelle de deux romans de 250+ pages transformés en articles*) consistant à aller copier coller le contenu de l’onglet « texte » dans Visual Studio Code (qui lui au moins fait apparaître toutes les balises si on lui spécifie qu’un fichier est html), faire le « find & replace » à partir de là pour remettre les &emsp; et enfin re-coller le tout à la place de son contenu dans l’onglet texte (et à la moindre modification du texte par une autre partie de l’éditeur, il y a un risque que toute l’opération soit à reproduire).

* En plus de risquer de ne pas être représentés par certains navigateurs du fait de comment les espaces simples sont gérés en html. La pratique recommandée est plutôt d’utiliser des &nbsp; ou autres pseudo-caractères similaires dès qu’il y a plus d’un espace à la suite (il se peut ou non que Divi ait eu la bonne idée d’automatiser le remplacement d’une suite d’espaces dans son volet visuel par des &nbsp; correctement pris en compte partout mais après tant de mauvaises surprises je n’irais pas parier là dessus).

C’est là où on voit le principal défaut de ce genre de thèmes, qui prétendent à la fois au confort de l’utilisateur et à une (relative) facilité d’utilisation tout en promettant de ne rien réduire des possibilités qu’offrent css et html.
A l’arrivée ce sont des choses bâtardes, ni très adaptées à permettre à quelqu’un qui souhaiterait ne rien coder d’aboutir facilement à un résultat précis qu’il voudrait, ni à quelqu’un utilisant du code d’en garder complètement le contrôle.

plutôt que d’utiliser son interface il y a un paquet de choses qu’on gagne à faire en code

C’est assez terrible vis à vis des promesses de Divi, mais plutôt que d’utiliser son interface il y a un paquet de choses qu’on gagne à faire en code et avant même d’y copier un article, et même une fois que c’est fait, mieux vaut utiliser le moins possible son interface pour le modifier (ou alors uniquement ce fameux onglet « texte », évitant à tout prix l’éditeur visuel de peur que Divi décide de réécrire tout à l’enregistrement). Ou il faut en tout cas s’en tenir strictement à un certain ordre pour faire les choses (et au bon endroit entre les 4 possibles où éditer un texte, éditeur externe compté), sans quoi on va au devant de déconvenues.

Les tooltips

C’est d’autant plus triste qu’il y a certains raccourcis de Divi, ce qu’on appelle des shortcodes, qui sont très faciles à utiliser, et qui à la différence du reste fonctionnent aussi bien quelle que soit la partie de l’éditeur où on les entre (ce qui rend très tentant de les mettre en œuvre à partir de l’éditeur visuel, comme je l’avais fait, entraînant hélas le problème évoqué plus haut).
Celui que j’ai le plus utilisé permet de placer des infobulles simplement en entourant un mot de deux balises tooltip, et en en renseignant le texte avec un « text=… » dans la première. Si les infobulles proposées par Divi nécessitent d’y ajouter un peu de css pour qu’elles soient jolies, ou si on veut les adapter à différentes tailles d’écrans, ça représente tout de même un gros gain de temps et de possibilités par rapport à avoir à mettre en place ces infobulles en code (et sans avoir à utiliser d’extension supplémentaire de WordPress, qui compliquent souvent inutilement les choses si beaucoup proposent des interfaces dédiées).

Pour ceux que ça intéresserait, voilà le css que je leur ai ajouté (à peu près le même que celui des tooltips utilisés sur cette pageQuelque chose comme ça...). Pour une autre version, voir celui de Dividude qui m’avait servi de base :

Et ensuite des adaptations à différentes tailles d’écran comme :

Etc. (les mêmes paramètres peuvent être ajustés plus précisément pour des tailles intermédiaires). L’intérêt de réduire leurs largeurs avec celles des écrans visant surtout à éliminer le plus possible de cas de figures où un tooltip dont le déclencheur serait en début ou fin de ligne risquerait d’en dépasser les bords. Quant à faire passer l’alignement du texte à left plutôt que justify quand les lignes des tooltips deviennent plus courtes, ça leur évite de gros espaces peu esthétiques entre les mots.

Quant à quelles tailles d’écran prévoir, il est intéressant de noter que le responsive de Divi utilise les largeurs suivantes :

• • • • • + de 1405 (écrans larges),
        • 980-,
        • 768 à 980 (tablettes en portrait ou longs smartphones en paysage),
        • 767- (plus petits smartphones en paysage, un tout petit nombre de modèles très larges en portrait – Galaxy S21, Smartisan M1L)
        • 479- (tous les autres smartphones en portrait)
        • et celle par défaut, qui est donc prévue pour un écran entre 980 et 1405 pixels de large.

        Si rien n’interdirait d’en utiliser d’autres au niveau du css personnalisé, autant en prendre qui correspondent avec ses propres ajustements (comme les changements de tailles d’image qu’il gère très bien automatiquement).

      •  

      • On notera à part ça le nombre de « !important » dans ce code css. S’il n’est pas toujours utile de spécifier qu’une instruction est importante, c’est que c’est un peu la seule manière d’être certain qu’une règle css sera bien prise en compte, quand WordPress, Divi (et éventuellement des extensions installées) sont pleins de réglages par défaut qui peuvent parfois eux même l’utiliser (ou sont susceptibles d’en rajouter à toute nouvelle version). A l’intérieur des règles signalées comme importantes, par contre, le css de l’utilisateur sera toujours prioritaire (et à l’intérieur de celui ci, les règles spécifiées dans les balises @media).

      •  

        Pour en revenir à mes mésaventures (et à un petit truc pouvant être utile) même l’usage des tooltips ne s’avéra pas totalement sans problème.
        Pour une raison mystérieuse ils se retrouvèrent dans un premier temps coupés par les limites de la boite de texte parente. Suite à quoi j’ai essayé à peu près toutes les méthodes logiques pour leur permettre d’en dépasser (leur donner un z-index:100, à eux à la boite en question, un overflow:visible, etc.) rien n’y changeait.
        C’est finalement complètement par hasard que j’ai découvert l’origine du problème en modifiant la présentation d’une page : j’avais utilisé l’interface styles de Divi pour mettre des bordures arrondies à mes fenêtres de texte, et manifestement dès qu’on le fait ça entraîne ce comportement (complètement illogique sachant que l’instruction css border-radius n’a quant à elle pas cet effet).
        Une solution tellement peu intuitive que je suis allé la donner derechef sur les forums de Divi des fois que quelqu’un rencontre le même problème .
        Une fois enlevés tous les arrondis réglés via l’interface de Divi, et les avoir remplacé par un border-radius renseigné au niveau du css personnalisé (pour la classe correspondant au corps de mes articles, que j’étais aller chercher via les outils de développeur d’un navigateur web, « .et_pb_section elements ») tout s’est mis à fonctionner parfaitement.
        En résumé encore un cas où l’interface graphique gagnait à ne surtout pas être utilisée plutôt que du code.

         

        Une page comptant plus de 40,000 mots

        D’autres problèmes ont aussi été rencontrés découlant de la quantité de texte que j’avais à convertir.
        Alors qu’un article de blog de plus de 5000 mots est généralement considéré excessivement long (la moyenne de ceux postés sur WordPress s’établissant même aux alentours de 300, selon son fondateur il y a quelques années, si ça doit être que beaucoup sont plutôt des fiches produit de sites d’e-commerce), le plus volumineux chapitre que j’avais à transformer en un article, quasiment au format d’une nouvelle, n’en comptait pas moins de 41540 et plus de 225000 caractères (quant à son code enrichi de balises et du texte des infobulles utilisées il atteignait les 250000), stressant plus qu’un peu un système pas vraiment prévu pour des pages aussi longues.
        Si aucun problème vraiment critique n’a été rencontré, l’éditeur s’est régulièrement retrouvé comme paralysé par les calculs qu’effectuait Divi pour correctement placer les tooltips ou mettre en forme le texte quand je travaillais dessus, entraînant un effet de lag très important quand j’y faisais des retouches, aboutissant parfois à une position de curseur non prise en compte (vous pensez vous être correctement placé à un endroit du texte où ajouter quelque chose, et vous retrouvez en fait à le faire tout en haut de la page, par exemple).
        Et à quelques reprises des sauvegardes automatiques effectuées dans ce contexte ont comme « oublié » certaines caractéristiques de la page (pour le pire qui me soit arrivé, tous les retours à la ligne ont à un moment disparu à l’échelle de paragraphes entiers à une récupération de la page, se retrouvant transformés en murs de texte indigestes, et à un autre toutes les infobulles ont cessées d’être traité comme telles et se sont mises à apparaître comme du texte visible sur la page toutes les balises n’ayant visiblement pas été correctement enregistrées).
        Heureusement, ces erreurs n’étant pas systématiques, l’historique de WordPress m’a toujours permis de corriger ces problèmes, soit en revenant complètement à une version de quelques minutes avant soit en allant récupérer dans une révision précédente la partie du texte ayant été corrompue.
        Le seul petit truc à savoir à ce niveau étant qu’avec WordPress/Divi on a accès à deux historiques séparés : celui limité à la session que propose Divi, répertoriant les modifications de la page depuis que l’éditeur a été ouvert (accessible via un click sur l’horloge dans sa barre d’icônes principale) et celui général de WordPress répertoriant toutes ses révisions enregistrées depuis sa création, auquel on peut accéder via l’onglet « révisions » de la barre à droite quand on utilise « modifier l’article » sans activer « éditer avec Divi ». Entre les deux il est quasiment impossible de perdre un état précédent auquel on pourrait vouloir revenir, mais encore faut il se rappeler que le second existe si on a plutôt l’habitude de modifier directement les articles via le Divi Builder.
        Et enfin que s’assurer que des sauvegardes soient faites au calme (attendre 30 secondes environ après toute modification importante pour en effectuer une manuelle, que l’éditeur ne soit pas en plein re-calcul) plutôt que de faire confiance aux automatiques, est la meilleure option quand on travaille sur une page aussi volumineuse.

        Je m’arrêterai néanmoins là, que cet article ne finisse pas aussi long que ce chapitre de roman. 🙂

        En conclusion, ce travail aura été très enrichissant pour m’apprendre toute une séries de petits trucs bons à connaître (ou pratiques à éviter) quand on travaille sur du WordPress/Divi. Cet article sonne peut être un peu négatif, vu qu’il évoque avant tout des problèmes rencontrés, mais cela ne signifie pas que Divi n’ait pas pour autant des aspects très appréciables.

      • Pour ce qui est de sa spécialité, la mise en place de modèles de pages, et le nombre de composants paramétrables qu’il propose d’y inclure, je n’ai par exemple absolument rien à lui reprocher et il fait certainement gagner du temps par rapport à la plupart des modèles WordPress pour ce qui est de développer une présentation personnalisée.Puis maintenant que j’ai pris le temps de découvrir tous ces petits trucs susceptibles de sauver un développeur Divi de la folie, je trouverais bête de ne pas l’utiliser.
        Comme en témoigne d’ailleurs le blog où nous nous trouvons, lui aussi réalisé sur Divi.

        

      •  

      • ps : le site en question se trouve ici.