[spip-dev] filtre url_absolue_css

Dev
1

Salut,

le plugin spipclear utilise le filtre |url_absolue_css qui est
documenté pour SPIP 1.9.2
http://www.spip.net/fr_article3567.html#url_absolue_css mais qui en
fait n'est présent que dans la branche SPIP 2.0

Par quoi est-il remplacé à ce jour ?

Amicalement,

2

Salut,

le plugin spipclear utilise le filtre |url_absolue_css qui est
documenté pour SPIP 1.9.2
SPIP 1.9.2 - SPIP mais qui en
fait n'est présent que dans la branche SPIP 2.0

Par quoi est-il remplacé à ce jour ?

tu veux dire qu'il n'est plus dans le branche dev ?
Il est possible qu'il soit sorti avec le compresseur (_plugins_/_core_/compresseur), je crois m'être posé la question à son sujet.

Cédric

3

il est chiant ce plugin compresseur :stuck_out_tongue:

1/ il compresse avec ou sans l'utilisation du filtre: on ne comprend
rien à ce qui se passe.
2/ il ne comprend pas les @import qui existent dans les fichier css et
donc ne les intègre pas.

4

James a écrit :

il est chiant ce plugin compresseur :stuck_out_tongue:

1/ il compresse avec ou sans l'utilisation du filtre: on ne comprend
rien à ce qui se passe.
[..]

Bonjour

Dans la config, tu peux préciser s'il doit compresser les CSS et le
javascript (ou les deux).

A bientôt
Grégoire

5

C'est au sujet de l'emploi ou non du filtre que je faisais la remarque.

6

il est chiant ce plugin compresseur :stuck_out_tongue:

1/ il compresse avec ou sans l'utilisation du filtre: on ne comprend
rien à ce qui se passe.

Desactive la compression pour les tests et le debug

2/ il ne comprend pas les @import qui existent dans les fichier css et
donc ne les intègre pas.

mmm, j'ai un doute. Je me souviens avoir géré les @import, mais c'etait peut etre pour le filtre direction_css.
Auquel cas il faudra completer url_absolue_css pour faire de même.
La question subsidiaire est je crois : doit on aussi propager url_absolue dans les css importees ?

Cédric

7

il est chiant ce plugin compresseur :stuck_out_tongue:

1/ il compresse avec ou sans l'utilisation du filtre: on ne comprend
rien à ce qui se passe.

Desactive la compression pour les tests et le debug

C'est ce que j'ai fait. Mais j'ai quand même été obligé de supprimer
le filtre. Bon disons que c'est un bug du filtre qui, dans certains
cas ne gère la règle @import.

Mais le soucis principal n'est pas là : calculer des urls aboslues
n'a, a priori, rien à voir avec la compression et faire toutes ces
manipulations de téléchargement de plugin, pour finalement le
désactiver est assez incohérent. Surtout quand il s'agit d'utiliser un
filtre indépendant de la fonctionalité...

Est-ce que c'est nécessaire de la placer hors du core ? Est-ce qu'en
fait, il ne devrait pas tout bonnement disparaitre des squelettes et
s'appliquer systématiquement dans le cas de la compression des css ?

2/ il ne comprend pas les @import qui existent dans les fichier css et
donc ne les intègre pas.

mmm, j'ai un doute. Je me souviens avoir géré les @import, mais c'etait peut
etre pour le filtre direction_css.

Je l'ai constaté en local, crois-moi sur parole, c'était flagrant :slight_smile:

Auquel cas il faudra completer url_absolue_css pour faire de même.
La question subsidiaire est je crois : doit on aussi propager url_absolue
dans les css importees ?

J'ai du mal à imaginer les conséquences, je répondrais 'oui' comme ça,
sans vraiment savoir.

8

C'est le cas : il est applique dès que on comprime ou on fait un direction_css qui necessite la reecriture de la css dans un autre répertoire.
C'est la raison pour laquelle je l'ai déménagé avec le compresseur, mais avec hésitation, et ton cas d'usage me fait penser effectivement qu'il vaudrait mieux le remettre dans le core.

Cédric

9

cedric.morin a écrit :

[...]
avec hésitation, et ton cas d'usage me fait penser effectivement qu'il
vaudrait mieux le remettre dans le core.

Cédric

Bonjour

J'aime bien qu'une partie se retrouve dans le _core_

Par exemple, le porte plume est buguée (la version que j'ai) et je
suis bien content de pouvoir le désactiver facilement (ou de changer
de version).

Peut être que le _core_ pourrait être livré par défaut...
Ça surprend au début de ne plus voir les statistiques :slight_smile:

A bientôt
Grégoire

10

Grégoire a écrit :

Par exemple, le porte plume est buguée (la version que j'ai) et je
suis bien content de pouvoir le désactiver facilement

C'est gentil de le dire... si tu le gardes pour toi, on peut rien faire !

11

Grégoire a écrit :

Peut être que le _core_ pourrait être livré par défaut...

C'est bien ce qui est prévu.

12

Matthieu Marcillaud a écrit :

Grégoire a écrit :

Par exemple, le porte plume est buguée (la version que j'ai) et je
suis bien content de pouvoir le désactiver facilement

C'est gentil de le dire... si tu le gardes pour toi, on peut rien faire !

Bonsoir

Je l'ai justement lu, ce qui m'a permis de comprendre ce qui
bloquait parfois la page (pas longtemps vu que Iceweasel indique le
script problématique et propose de l'interrompre).

Ce bug est donc connu, c'est une incompatibilité du plugin avec la
version SVN de Spip.

C'est juste un cas particulier.

A bientôt
Grégoire

13

Grégoire a écrit :

Matthieu Marcillaud a écrit :

C'est gentil de le dire... si tu le gardes pour toi, on peut rien faire !

Ce bug est donc connu, c'est une incompatibilité du plugin avec la
version SVN de Spip.

Non, il n'y a plus de bug normalement avec la version SVN de SPIP que ce soit la 2.0 ou la 2.1 dev. Donc le bug que tu sembles indiquer n'a pas à se produire (vérifier que les caches sont bien vidés, SPIP et navigateur !). Il provenait, sur la 2.1 dev de jQuery 1.3 qui était buggué, remplacé maintenant par jQuery 1.3.1.

Alors, bug ou pas au bout du compte ?

14

Matthieu Marcillaud a écrit :

Grégoire a écrit :

Matthieu Marcillaud a écrit :

C'est gentil de le dire... si tu le gardes pour toi, on peut
rien faire !

Ce bug est donc connu, c'est une incompatibilité du plugin avec
la version SVN de Spip.

Non, il n'y a plus de bug normalement avec la version SVN de SPIP
[...] la 2.1 dev de
jQuery 1.3 qui était buggué, remplacé maintenant par jQuery
1.3.1.

Alors, bug ou pas au bout du compte ?

Bonjour

J'ai vu que tu avais suivi le fil dans Spip-zone, normal, tu es
l'auteur de ce plugin.

Tu écris le 21 janvier :

En fait, ça prend les classes de MarkItUp (mais ça c'est réglé),
mais surtout, ça prend les classes de formulaire_spip ... et
là... c'est loin d'être réglé !

C'est la dernière partie qui m'inquiète.
Je ne peux que essayer après une mise à jour et te tenir au courant.
(je viderai proprement tous les caches)

Bonne nuit
Grégoire

15

Matthieu Marcillaud a écrit :

Grégoire a écrit :

Matthieu Marcillaud a écrit :

C'est gentil de le dire... si tu le gardes pour toi, on peut rien
faire !

[...]
remplacé maintenant par jQuery 1.3.1.

Alors, bug ou pas au bout du compte ?

Bonsoir

J'ai mis à jour le moteur Spip svn avec la version 13659 et aussi le
plugin porte-plume avec la version d'aujourd'hui (26/01/2009), vidé
le cache et tout fonctionne très bien.

La prévisualisation est presque instantanée, c'est merveilleux.
Merci

Bonne soirée
Grégoire