Changer de coloration syntaxique avec WordPress
Il n’y a pas si longtemps, j’ai changé de coloration syntaxique sur mon blog,
et j’en donnerai les raisons. Lorsqu’on change ce système, la syntaxe pour
activer la coloration peut être modifiée, il faut donc rectifier tous les
billets, et comme je n’ai pas l’intention de le faire à la main, un par un, il
convient de trouver une méthode ou une autre. Rien de compliqué, se résumant à
un sed
sur la base de donnée, mais qui peut-être, pourrait être utile au plus
novice d’entre nous.
Choix du plugin de coloration syntaxique
J’ai longtemps, utilisé le plugin WP-syntax, qui est probablement un des plus utilisés, et il est très bien, cependant, il ne permet pas vraiment de personnalisation du CSS. Il permet bien quelques modification, mais ne propose pas de changement de thèmes, de même que j’en ai pas trouvé sur le web, et je ne pense pas qu’il soit facile de le faire soi-même. Hors, je recherchais une coloration syntaxique proposant un fond noir, avec un thème suffisement agréable.
C’est là que je suis tombé sur CodeColorer, un plugin qui va répondre mes attentes.
Première chose, je n’aurais pas changé pour un plugin supportant moins de langage, et là, les deux plugins sont basé sur le même moteur de coloration, à savoir GeSHi, parfait, il supporte bien plus de langage que je n’en connaissais même de nom.
Un autre détail, que je n’ai découvers que après, c’est que CodeColorer permet d’obtenir une coloration syntaxique dans les lecteurs RSS (normalement) chose que WP-syntax ne fait pas, et c’est plutôt bien, d’avoir un beau code à lire même sans visiter le site, puisque après tout, c’est avant tout pour rendre agréable la lecture, autant que ce soit coloré là où on le lis.
Ça me suffit pour me motiver à l’essayer, ce n’était pas la seul solution, et certain, voudront peut être regarder le plugin basé sur pygment (python). Cependant avec un hébergement mutualisé, il sera plus difficile à mettre en place.
Migration en quelques minutes
le problème est simple, voici comment on active la coloration pour chaque plugin:
- WP-syntax:
- CodeColorer:
Y a pas grand chose de différent, mais ça suffit pour ne pas fonctionner, et se retrouver sans aucune coloration syntaxique si ce n’est pas modifié.
La modification va se faire en trois étapes:
- On fait une copie de la base de donnée
- On fait le changement de façon globale avec sed (ou directement dans vim)
- On remplace la base de donnée
Comme le billet est plutôt pour débutant, il est plus probable que vous êtes sur un hébergement mutualisé ou autre, mais sans accès à une console, si vous aviez un accès SSH, la tâche en serait biensûr facilité. Il y a certainement d’autre méthodes également, et franchement, j’ai pris la première idée qui me semblait pratiquable rapidement. Et si ça peut vous rassuré, je l’ai fait, ça fonctionne.
- Exporter sa base
Deux choix, l’un est un plugin que j’avais depuis bien longemps, qui permet d’automatiser la sauvegarde de base de donnée wp-db-backup, utile lorsqu’on ne peut pas vraiment avoir un accès SSH pour automatiser, et simplification pour avoir quand même une sauvegarde sql journalière. Une fois installé, vous avez un lien backup dans outils avec comme page d’administration un gros bouton pour vous envoyer à une adresse mail les tables utiles à votre wordpress.
L’autre choix, avec phpMyAdmin, vous vous connectez sur votre interface web, et selectionné « export », on selectionne la base « wp_posts » et on click tout à bas à droite sur « go », c’est tout simple, pas besoin de screenshot pour ça.
- Modifier la base
Avant toute modification, assurez vous d’en avoir une copie intacte quand même, on sait jamais ;)
Perso, j’ai simplement pris vim, avec les deux commandes suivantes:
:%s/<\\/pre/<\\/code/g
Mais sed est aussi efficace, pour un fichier par exemple backup.sql:
sed -i 's/<\\/pre>/<\\/code>/g' backup.sql
- Réintroduire sa base
Nous retournons sur la page de phpMyAdmin, mais cette fois ci, au lieu d’exporter, nous faisont l’inverse, on click sur « import ». On copie-colle le résultat obtenu, du fichier backup.sql dans la grande case de saisie, et on valide, quelques instant plus tard, tout les posts ont une syntaxe valide pour votre plugin fraîchement installé.
Conclusion
La manipulation est rapide, pouvant être utilisé dans d’autre cas, il faut
quand même faire attention en utilisant des sed
sur une base de données,
surtout de ne pas changer des données pour lequels il n’était pas prévu.