Alors comment vais-je débugguer les squelettes si je ne peux
pas lire dans les sources html le texte que je mets en
commentaire?
C'est très pratique avec le débuggueur de Firefox, ça permet de
suivre le déroulement des squelettes sans toucher à l'apparence
de la page ni nécessiter d'être identifié.
Les commentaires html ne sont pas supprimés du tout, justement
c'est la compression que les supprimait (enfin je crois, je
l'utilise jamais). Ou alors j'ai pas compris...
Bonsoir,
je me suis mal exprimé.
Dans mes squelettes, j'utilise les commentaires html pour me donner
des indications :
<!-- skel-machin ligne 40 - A : #ID_ARTICLE - R : #ID_RUBRIQUE -
machin : [(#GET{machin})] -->
Comme mes squelettes sont partagés par plusieurs sites, je peux
désactiver la compression html et voir avec le débuggeur où j'en
suis, et éventuellement en vérifiant que j'ai bien le résultat
attendu d'une fonctionnalé si l'ensemble du code généré est dans un
commentaire html. Je peux aussi faire le test sans être authentifié.
Bref, ça me permet de travailler sur le serveur, éventuellement sur
une version différente de mes squelettes, ou de tenter de debugguer
un problème qui surgit, de manière confortable.
Je n'efface pas les commentaires, c'est trop long à ajouter, donc je
les laisses, mais sur les sites en production, j'active leur
suppression par l'option de compression html, qui se fait site par
site, et c'est bien son intérêt.
Par exemple, sur http://guolang.gites-voyages.com/ j'ai désactivé la
compression html. Inutile de me parler du problème d'encodage des
caractère, l'importation d'un backup (foireux?) s'est mal passée
pour ce site.
La suppression des commentaires html permet de rendre le code plus
concis.
Les exceptions pour les commentaires conditionnels sont pris en
compte, pourquoi pas. <!--[if lt IE 8]>
Pourquoi ne pas ajouter d'autres exceptions? ou corriger les plugins
qui sont incompatibles? ou bien que lors de l'installation du plugin
il y ait un avertissement lorsque la compression html est activée?
(et pareil sur l'option). Oui, c'est beaucoup de travail.
Le disfonctionnement de la compression html est rare compte tenu du
nombre de plugins qui s'en accomodent.
"Salut, je recommanderais plutôt de ne pas utiliser la
compression HTML car celle-ci pose souvent problème. J'ai
dernièrement rencontré un souci avec un plugin qui n'insérait
pas le contenu prévu dans les pages du site car le
preg_replace qui devait le faire ne matchait pas l'expression
cherché à cause des sauts de lignes générés dans le source
par la compression HTML."
Je trouve que c'est crade qu'UN plugin ait un problème à cause
d'un changement du nombre de lignes. Pourquoi se baser sur le nombre
de lignes? (je peux regarder le code source...)
Peut être qu'il faudrait un drapeau au niveau des plugins pour que
la compression html ne soit pas problématique pour ce/ces plugins
(ça demande du temps et du travail, je sais).
Des conflicts entre plugins, ça existe. Là, on est dans un cas ou
un/des plugins sont incompatibles avec une option de Spip. C'est
facile à tester et d'afficher une alerte pour le webmestre, non?
GIS 4 - SPIP-Contrib
Pareil, si la présence de données json est cassée par la compression
html (ah???), il faut créer une exception, ou corriger le code, ou
bien afficher une alerte pour le webmestre en cas de présence de
code json sur la page (et le webmestre prendra alors une décision
éclairée).
Voilà, avec la suppression de la compression html, Spip 3.1 régresse
vers la mauvaise qualité des plugins Wordpress dont aucun jusqu'à
présent ne faisaient un aussi bon travail de compression html/css/js
que Spip. Ne vous inquiétez pas, il reste de la marge.
Cette décision ayant été prise il y a 3 ans, je suppose que c'est
trop tard.
Dommage.
A+