Une mise à jour de ce plugin qui permet la coloration syntaxique du code que vous publiez dans vos billets : Ajout de quelques unités de mesure et de tout ce qui concerne les flexbox du côté Sass et CSS.
Il permet, une fois activé (voir la figure ci-dessus), l’ajout d’un bouton supplémentaire sur la barre d’outils d’édition des billets et des pages :
L’activation de ce bouton permet, une fois précisé la syntaxe à utiliser, d’afficher le code coloré syntaxiquement :
Ce plugin intègre la version 3.0.9 du script SyntaxHighlighter. La sélection du thème CSS utilisé pour le rendu se fait sur la page de réglage du plugin.
Ce billet servira de support pour cette version du plugin.
1 De Pinkilla -
Merci …
2 De gnieark -
Hello,
Pour info, je me suis permis de faire un petit fork de ce plugin
https://github.com/SoftBellies/yash…
afin de concaténer les JS et les CSS générés par yash.
Par contre, il est probable que mon fork ne respecte pas tout à fait les beast practices dotclear. (faut que je trouve un moyen plus propre que d’écrire un fichier dans le repertoire du plugin)
Il est activé sur mon blog et sur https://www.ventresmous.fr/
Gnieark
3 De Franck -
Hello gnieark, j’ai vu passer ça oui. À ce sujet je me demande si le fait de concaténer les fichiers ne va pas bientôt aller à l’encontre de ce qui se met en place côté HTTP/2, qui privilégie le chargement en parallèle des ressources.
Pour la gestion des fichiers propres aux plugins, tu peux utiliser le dossier var, il a été introduit pour ça. J’en parle brièvement ici.
Ce répertoire s’utilise comme le dossier cache (voir un exemple d’application avec le rapport CSP que j’ai recodé il n’y a pas très longtemps), mais en utilisant la constante DC_VAR qui définit son chemin, et il est préconisé de se créer un dossier dedans au nom du plugin, yash3 dans ton cas, et éventuellement à l’intérieur de celui-ci autant de dossiers que de blogs si les fichiers étaient spécifiques à chacun d’entre eux. Mais là, c’est toi qui vois, c’est ta tambouille :-)
4 De gnieark -
Merci Franck pour les indications sur le dossier cache var. Je lis ça et modifierai yash3.
Pour le choix de concaténer les fichiers, je te rejoins, mais dans ce cas précis: vu que le premier JS ne sera pas utile tant que le dernier JS n est pas chargé. Le chargement en parallèle des JS ne permettrait pas de commencer les modifications qu ils font sur la page en parallèle. Autant tout envoyer d un coup et faire l économie de quelques requêtes.
5 De Franck -
Je pense que c’est un peu plus subtil que ça, pour HTTP/2, puisque que c’est la taille des ressources chargées qui influe sur l’ensemble, pas vraiment l’exécution des scripts.
Si jamais le résultat de ta concaténation était sur le chemin critique, alors il aurait un impact réel sur le temps de réponse global (non compte-tenu des aléas des transmissions de chacune des connexions TCP ouvertes, évidemment).
Maintenant si jQuery est chargé aussi, ou la CSS Bootstrap, alors pas de souci, ces deux-là sont quoi qu’il en soit bien plus lourds que yash.
Et tout ça n’est qu’un aspect du problème (cache ou pas cache, CDN ou pas, minification ou pas, …)
6 De rfrp -
Muchas gracias! El plugin funciona fantástico y los códigos se ven muy bien a la vista.
Saludos,
7 De Logrus -
Bonjour, et merci pour avoir pris la relève du vénérable syntaxehl désormais incompatible. Il va falloir que je reprenne tous mes billets, mais au moins la coloration fonctionnera !
J’en profite pour une petite feature request : serait-il possible de réexposer dans le plugin les options de configuration proposées par SyntaxHighlighter ? (comme la présence ou non des numéros de ligne, etc.)
8 De Logrus -
…et j’oubliais, est-ce que le plugin pourrait-il être rendu compatible avec l’ancienne syntaxe de syntaxehl ? Par exemple en autorisant à configurer le sélécteur qui active le plugin (actuellement: ///yash lang, pourrait être changé en: ///[lang]).
Je pense que cela sauverait pas mal de bloggers…
9 De Franck -
Je note les évolutions demandées, et j’empile sur ma liste de choses à faire… :-)
10 De Logrus -
Super :)
11 De Franck -
Alors après avoir un peu regardé le plugin SyntaxeHL, ça ne sera pas aussi automatique parce qu’il mettait en place la présentation (coloration syntaxique) directement dans la version HTML enregistrée du billet. Yash de son côté, se borne à ajouter un attribut particulier à l’élement <pre> qui englobe le code et c’est ensuite côté public que le gros est fait, via du code Javascript exécuté sur la machine du visiteur.
Donc ce que je prévois c’est de permettre de conserver le sélecteur de SyntaxeHL mais pas plus. Le reste fonctionnera comme Yash le fait depuis toujours.
Au passage tous les langages supportés par SyntaxeHL ne le seront pas par Yash.
Pour résumer, un ancien billet traité avec SyntaxeHL et son sélecteur habituel sera reconnu par Yash s’il est ré-édité et traité en conséquence, mais pas plus.
12 De Logrus -
Merci d’avoir pris le temps d’examiner la question, c’est super sympa !
Personnellement, la solution proposée me convient parfaitement - le but était d’éviter d’avoir à rééditer des centaines de blocs de code pour changer ///java en ///yash java.
Et techniquement, je trouve ça beaucoup plus intelligent de ne pas polluer le code du billet avec du formatage intégré, et de laisser des “coloriseurs” du marché faire leur boulot côté client - ne serait-ce que pour le support des thèmes graphiques.
J’ai hâte que la nouvelle version du plugin soit disponible :)
13 De Franck -
Elle l’est depuis samedi dernier ;-)