Salut,
Un petit bug découvert avec le filtre |direction_css dans SPIP :
Quand j'applique le filtre, SPIP me genere la css dans le cache, bien, mais le lien n'est pas bon quand c'est une css dynamique :
[<link rel="stylesheet" type="text/css" href="(#URL_PAGE{stylessoyezcreateurs.css}|direction_css)" media="all" />]
me donne local/cache-css/spip.php?page=stylessoyezcreateurs.1b1c_rtl.css
mais le lien n'est pas bon, il faut que ce soit : local/cache-css/spip.php%3Fpage=stylessoyezcreateurs.1b1c_rtl.css pour que ça marche.
* Yohann Prigent tapuscrivait, le 22/10/2009 12:24:
Salut,
Un petit bug découvert avec le filtre |direction_css dans SPIP :
Quand j'applique le filtre, SPIP me genere la css dans le cache, bien, mais le lien n'est pas bon quand c'est une css dynamique :
[<link rel="stylesheet" type="text/css" href="(#URL_PAGE{stylessoyezcreateurs.css}|direction_css)" media="all" />]
me donne local/cache-css/spip.php?page=stylessoyezcreateurs.1b1c_rtl.css
mais le lien n'est pas bon, il faut que ce soit : local/cache-css/spip.php%3Fpage=stylessoyezcreateurs.1b1c_rtl.css pour que ça marche.
De plus, sous Windows, le fichier ne peut pas être écrit car "?" est interdit dans un nom de fichier.
Ce n'est pas suffisant pour Windows.
En effet, le fichier écrit contient toujours "?" qui n'est pas valide
Du coup :
vérifier les droits d'écriture
Le système a rencontré une erreur lors de l'écriture du fichier local/cache-css/spip.php?page=stylessoyezcreateurs.9ecb_rtl.css. Veuillez, en tant qu'administrateur du site, vérifier les droits d'écriture sur le répertoire local/cache-css
Encore dans mes recherches, j'ai vu que ce filtre ne gérait pas du tout les css dynamiques. Il compilait, mais sans contexte de la langue...
J'ai donc fais un petit patch (je ne sais pas si c'est assez propre) :
--- Sites/SPIP/createurs/ecrire/inc/filtres.php (révision 14644)
+++ Sites/SPIP/createurs/ecrire/inc/filtres.php (copie de travail)
@@ -1939,7 +1939,7 @@
// 2. sinon la cree (ou la recree) dans _DIR_VAR/cache_css/
// SI on lui donne a manger une feuille nommee _rtl.css il va faire l'inverse
// http://doc.spip.org/@direction_css
-function direction_css ($css, $voulue='') {
+function direction_css ($css, $dynamique=false, $voulue='') {
if (!preg_match(',(_rtl)?\.css$,i', $css, $r)) return $css;
// si on a precise le sens voulu en argument, le prendre en compte
@@ -1972,16 +1972,23 @@
// la css peut etre distante (url absolue !)
if (preg_match(",^http:,i",$css)){
include_spip('inc/distant');
- $contenu = recuperer_page($css);
+ // cas des css dynamiques en SPIP
+ if ($dynamique = 'dyn')
+ $contenu = recuperer_page($css.'&lang='.$GLOBALS['lang']);
+ else
+ $contenu = recuperer_page($css);
if (!$contenu) return $css;
}
else {
if ((@filemtime($f) > @filemtime($css))
AND ($GLOBALS['var_mode'] != 'recalcul'))
return $f;
- if (!lire_fichier($css, $contenu))
+ if ($contenu = recuperer_fond($css))
return $css;
}
+
+ if (strstr($f, '?'))
+ $f = str_replace('?', '_', $f);
$contenu = str_replace(
array('right', 'left', '@@@@L E F T@@@@'),
@@ -2015,7 +2022,7 @@
if (!ecrire_fichier($f, $contenu))
return $css;
-
+
return $f;
}
Concrètement, si y'a le paramètre 'dyn' dans le filtre, ça récupère la page avec la variable &lang='.$GLOBALS['lang']
regarde la css prive de SPIP par exemple.
Sinon, la bonne methode est d'extraire les lignes 1986 a 2014 de inc/filtres.php, et de les mettre dans un filtre dedie, et d'ajouter a ton squelette #FILTRE{changededirection}
* cedric.morin@yterium.com tapuscrivait, le 22/10/2009 21:14:
Sinon, la bonne methode est d'extraire les lignes 1986 a 2014 de
Moi, j'avais compris que la bonne méthode avec SPIP, c'était de tomber sur des usages imprévus mais logiques, de les faire remonter et que, si c'est logique, SPIP en tient compte.
Par exemple, il fut un temps où les redirections d'article ne pouvait pointer que sur des URL web (absolues ou relatives).
Et puis un jour, j'ai voulu faire une redirection vers art1
Et ça n'a pas marché.
C'était pourtant un usage cohérent.
Du coup, ça a été intégré.
Du point de vue d'un créateur de squelettes, une CSS est une CSS, qu'elle soit dynamique ou non.
Il y a un filtre direction_css qui permet d'adapter une CSS à la langue de la page.
Il est surprenant qu'il plante sur une CSS, fusse-t-elle dynamique.
Et la doc |direction_css - SPIP parle :
Le filtre |direction_css appliqué à un fichier css (feuille de styles)
Il n'est pas fait mention que cette CSS ne peut pas être une feuille calculée par SPIP...
Autre tentative de contournement qui tombe elle aussi sur un bug de consistance de comportement :
[<link rel="stylesheet" type="text/css" href="(#URL_PAGE{stylessoyezcreateurs.css}|copie_locale|direction_css)" media="all" />]
copie_locale ne tient pas compte du type mime du fichier indiqué dans
les header HTTP et crée donc un fichier :
IMG/distant/html/spipphppages9ecb.html
Ce cas ne me semble pas isolé : on peut très bien avoir besoin de faire une copie_locale d'un document distant servit par un script.
Il serait logique qu'à l'enregistrement, l'extension donnée au fichier corresponde au type mime.
Non ?
* cedric.morin@yterium.com tapuscrivait, le 22/10/2009 21:14:
Sinon, la bonne methode est d'extraire les lignes 1986 a 2014 de
Moi, j'avais compris que la bonne méthode avec SPIP, c'était de tomber sur des usages imprévus mais logiques, de les faire remonter et que, si c'est logique, SPIP en tient compte.
Je propose une solution, justement.
Du point de vue d'un créateur de squelettes, une CSS est une CSS, qu'elle soit dynamique ou non.
Il y a un filtre direction_css qui permet d'adapter une CSS à la langue de la page.
Il est surprenant qu'il plante sur une CSS, fusse-t-elle dynamique.
Et la doc |direction_css - SPIP parle :
Le filtre |direction_css appliqué à un fichier css (feuille de styles)
Il n'est pas fait mention que cette CSS ne peut pas être une feuille calculée par SPIP...
Si on fait dans l'explication de texte, la doc dit clairement "un fichier css", pas "une url" ...
Hors ce que tu lui fournis n'est ni plus ni moins qu'une url, et non un chemin vers un fichier.
* Yohann Prigent tapuscrivait, le 28/10/2009 00:16:
Le patch n'était pas optimisé :s
+ // Si elle est distante, on commence a preparer le chemin de la css
On se fout complètement de savoir si elle est distante ou pas.
Le fonctionnement actuel fait *déjà* un récupérer page.
Le seul problème est le nom du fichier résultant.
Actuellement, on a :
1) si lang_dir = ltr, on ne fait rien de plus
2) sinon, on récupère le contenu de l'url indiquée
3) on fait les traitements pour inverser les left et right
4) on rajoute rtl à l'url qu'on raccourcis avec un peu de md5 et on s'en sert comme nom de fichier. (entre 1 et 2, il y a aussi une vérification que ce fichier n'existe pas déjà pour éviter d'avoir à le refaire)
Donc, direction_css est déjà actuellement agnostique quant à la nature du processus de génération de la css à inverser (qu'elle soit fabriquée par un humain, un php, un squelette, un pigeon...).
Ce n'est que le nom du fichier généré qui pose problème.
* Yohann Prigent tapuscrivait, le 28/10/2009 00:16:
Le patch n'était pas optimisé :s
+ // Si elle est distante, on commence a preparer le chemin de la css
On se fout complètement de savoir si elle est distante ou pas.
Si, si elle est distante, il faut vérifier si le Content-Type est bien du CSS. Ce filtre ne s'applique qu'à du CSS pas à autres choses
Le fonctionnement actuel fait *déjà* un récupérer page.
Le seul problème est le nom du fichier résultant.
Le problème du nom de fichier est dans le patch, on enlève tous les caractères exotiques quand on prépare le chemin.
Actuellement, on a :
1) si lang_dir = ltr, on ne fait rien de plus
2) sinon, on récupère le contenu de l'url indiquée
3) on fait les traitements pour inverser les left et right
4) on rajoute rtl à l'url qu'on raccourcis avec un peu de md5 et on s'en sert comme nom de fichier. (entre 1 et 2, il y a aussi une vérification que ce fichier n'existe pas déjà pour éviter d'avoir à le refaire)
C'est exactement ce que fait le patch mais en faisant une vérification supplémentaire sur le Content-Type et en renommant le fichier de sorte à ne garder que ce qui est après le ? d'appel dans le cas d'un script php et surtout d'enlver tous les caractères pas bon.
Donc, direction_css est déjà actuellement agnostique quant à la nature du processus de génération de la css à inverser (qu'elle soit fabriquée par un humain, un php, un squelette, un pigeon...).
Ce n'est que le nom du fichier généré qui pose problème.