Chose qu’on a jamais transcrite dans la déclaration XML.
Il apparait aujourd’hui qu’on a le problème sur le compresseur, dont la fonction devrait être appelée en dernier sur le pipeline header_prive, pour être en mesure de compacter tous les JS et CSS ajoutés dans le pipeline par les plugins.
Le problème n’apparait que dans l’espace privé, parce qu’on a géré un peu différemment de l’espace public.
Pour corriger, soit je repasse par une globale, soit on ajoute un attribut sur la déclaration pipeline de la 3.3 ?
Je pencherai plutôt sur cette dernière solution, question serait alors quel attribut ?
- soit un attribut homonyme de sa valeur genre « last » qui peut prendre la valeur « last » uniquement
- soit carrément on améliore pour un attribut plus générique genre « position » ou « priorite » qui pourrait prendre les valeurs « first » ou « last » avec la possibilité peut-être un jour d’accepter des positions numériques ?
Je ne pense pas corriger le bug en 3.2, c’est pas fondamental, et en 3.3 on a l’avantage de s’être débarrassé du plugin.xml, donc plus d’équivalence à gérer…
Mais par contre est-ce qu’on pourra éviter une erreur si ce même paquet.xml est utilisé en 3.2 ou 3.1 (même sans prise en compte de l’attribut) ?
- soit un attribut homonyme de sa valeur genre « last » qui peut prendre la valeur « last » uniquement
- soit carrément on améliore pour un attribut plus générique genre « position » ou « priorite » qui pourrait prendre les valeurs « first » ou « last » avec la possibilité peut-être un jour d’accepter des positions numériques ?
Priorité, ou position semble plus indiqué quitte à ajouter quelque chose, non ?
Je ne pense pas corriger le bug en 3.2, c’est pas fondamental, et en 3.3 on a l’avantage de s’être débarrassé du plugin.xml, donc plus d’équivalence à gérer…
Mais par contre est-ce qu’on pourra éviter une erreur si ce même paquet.xml est utilisé en 3.2 ou 3.1 (même sans prise en compte de l’attribut) ?
J’ai une belle erreur dans l’admin des plugins de 3.3 ou 3.2 dès qu’on ajoute un attribut qui n’est pas censé exister.
Du coup je doute qu’on puisse éviter le problème sur les installations existantes, sans mise à jour de SPIP ou sans branche dédiée pour les plugins...
Non la dtd refuse la validation car l’attribut n’est pas défini même si il n’est pas obligatoire. Le mieux est à mon avis de back porter en 3.2 et pour les autres versions tant pis il faudra faire une branche de plugin pour utiliser la fonctionnalité.
Et si on hack ? en mettant || en début du nom de l’action pour reprendre la vieille syntaxe ?
ah mais ça va faire foirer les vieux SPIP peut-être ? ou en combinant avec une balise <spip> ?
Non la balise spip ne changera rien car l’attribut n’est pas reconnu par la
dtd. Mais si on met ça sur la 3.3 ça veut dire que ça fonctionne uniquement
pour cette version. Pour le compresseur c’est bon et pour les autres
plugins qui veulent et bien ils branchent non ?
Est ce que plutôt de position numérique ce ne serait pas un position
vis d'autres plugins. Car si on a 2 plugins qui disent "dernière
position/priorité" comment sera géré leur ordre ? De plus si c'est
une valeur numérique, la "position" n'a pas grand sens car on ne sait
combien de plugins on a et dans les positions possibles.
Si 2 plugins disent « en dernier » on ne peut pas discriminer.
Mais si/quand le cas se présente sur le même pipeline (c’est quand même des usages assez rares, on a pas eu de telle collision jusqu’ici), on peut discriminer en ajoutant un utilise/necessite dans celui qui doit vraiment être le dernier.
Et dans le cas de valeurs numériques, ce seraient des niveau de priorité, à définir selon une échelle fermée ou ouverte (comme les z-index CSS).
Tu peux jamais être sur que quelqu’un ne va pas passer derrière, mais si tu mets 10000 tu as de bonnes chances
Et pour répondre à ta question, non ce n’est pas vis à vis d’autres plugins.
Typiquement pour compresseur, on veut qu’il passe en dernier sur le head pour tout compresser, quels que soient les plugins installés qu’il ne connait même pas.
Définir une liste de ces plugins serait compliqués et vain…
