Salut,
Ça serait pas mal d'établir une liste des incompatibilités constatées au passage à la 2.1. Personnellement, ces incompatibilités ne me posent pas de gros soucis moraux, en revanche ce serait pas mal d'avoir quelque part une petite liste, avec les solutions, pour ceux qui y seraient confrontés. Notez que ça touche aussi bien les sites eux-mêmes que les plugins développés pour SPIP.
Pour ma part, voici les différentes choses que j'ai rencontrées.
Je propose la tournure suivante:
- Utilisation d'un filtre dont l'existence est conditionnelle (notamment: présence d'un plugin): par exemple
[(#PLUGIN{accesrestreint}|oui)
[(#ID_ARTICLE|accesrestreint_article_restreint|oui) <INCLURE{fond=zones/structure}{...} /> ]
]
-> SPIP 2.1 teste l'existence des filtres a la compilation, et non a l'exécution. Du coup, ici il ne trouve pas le filtre "accesrestreint_article_restreint" quand le plugin "accès restreint" n'est pas actif.
Dans ce cas particulier, il faut écrire
[(#ID_ARTICLE|filtrer{accesrestreint_article_restreint})]
au lieu de
[(#ID_ARTICLE|accesrestreint_article_restreint)]
http://trac.rezo.net/trac/spip/ticket/1862
A*
Mon, 1 Mar 2010 15:39:42 +0100, Arnaud:
- jQuery: les appels du type $("input[@name=prenom]") sont dépréciés
et ne fonctionnent plus dans la nouvelle version de jQuery (1.4.2)
Étant donné que ce sont des incompatibilités d'une biliothèque
non-SPIP, peut-être est-il possible de juste mentionner "utilisation de
jQuery 1.4.2" et simplement renvoyer vers les changements introduits par
ce dernier sur le site de jQuery.
Ah non, la fonction filtrer n'a qu'un seul argument et ne peut s'utiliser que comme ceci : #VAL{accesrestreint_article_restreint}|filtrer
Pat
Au temps pour moi.
Il n'y a donc pas d'alternative utilisable dans les squelettes, sauf à réformer la fonction
// http://doc.spip.org/@appliquer_filtre
function appliquer_filtre($arg, $filtre, $default=NULL) {
$f = chercher_filtre(preg_replace('/\W/','_', $filtre), $default);
return !$f ? '' : $f($arg);
}
en supprimant le troisième argument au profit des arguments suivants du filtre cible, ce qui permettrait l'écriture
[(#TRUC|appliquer_filtre{nomdufiltre,arg2,arg3,...})]
La fonction appliquer_filtre n'étant utilisée qu'une seule et unique fois dans SPIP, dans public/composer :
$corps = appliquer_filtre($corps, $filtre,'filtre_identite');
je propose donc de supprimer l'argument $default en le remplaçant dans le corps de la fonction par 'filtre_identite'.
Sinon, cela veut dire qu'il faut introduire une nouvelle fonction ressemblante, ce qui va faire beaucoup de fonctions "presque pareilles".
Emmanuel, puisque c'est toi qui a introduit appliquer_filtre, en as tu une utilisation qui requiert le 3ème argument ou peux-t-on changer la signature de la fonction ?
Cédric
Au temps pour moi.
Il n'y a donc pas d'alternative utilisable dans les squelettes, sauf à réformer la fonction
// http://doc.spip.org/@appliquer_filtre
function appliquer_filtre($arg, $filtre, $default=NULL) {
$f = chercher_filtre(preg_replace('/\W/','_', $filtre), $default);
return !$f ? '' : $f($arg);
}en supprimant le troisième argument au profit des arguments suivants du filtre cible, ce qui permettrait l'écriture
[(#TRUC|appliquer_filtre{nomdufiltre,arg2,arg3,...})]
La fonction appliquer_filtre n'étant utilisée qu'une seule et unique fois dans SPIP, dans public/composer :
$corps = appliquer_filtre($corps, $filtre,'filtre_identite');
non, elle est utilisée dans plusieurs modèles, qui comptent sur la valeur par défaut.
Sinon, cela veut dire qu'il faut introduire une nouvelle fonction ressemblante, ce qui va faire beaucoup de fonctions "presque pareilles".
J'ai pas pris ce fil par le début. Est-ce que chercher_filtre ne suffirait pas ?
Committo,Ergo:Sum
Au temps pour moi.
Il n'y a donc pas d'alternative utilisable dans les squelettes, sauf à réformer la fonction
// http://doc.spip.org/@appliquer_filtre
function appliquer_filtre($arg, $filtre, $default=NULL) {
$f = chercher_filtre(preg_replace('/\W/','_', $filtre), $default);
return !$f ? '' : $f($arg);
}en supprimant le troisième argument au profit des arguments suivants du filtre cible, ce qui permettrait l'écriture
[(#TRUC|appliquer_filtre{nomdufiltre,arg2,arg3,...})]
La fonction appliquer_filtre n'étant utilisée qu'une seule et unique fois dans SPIP, dans public/composer :
$corps = appliquer_filtre($corps, $filtre,'filtre_identite');non, elle est utilisée dans plusieurs modèles, qui comptent sur la valeur par défaut.
Ah effectivement je ne les avait pas vu.
Sinon, cela veut dire qu'il faut introduire une nouvelle fonction ressemblante, ce qui va faire beaucoup de fonctions "presque pareilles".
J'ai pas pris ce fil par le début. Est-ce que chercher_filtre ne suffirait pas ?
Non, le problème est de pouvoir appliquer un filtre dans un squelette si il est présent à l'exécution, ce que l'erreur générée à la compilation empêche désormais dans l'écriture classique.
Ces cas existent et on a plus de solution d'écriture sauf filtrer, mais en indiquant le nom du filtre en premier argument, ce qui est très peu pratique.
On ne va tout de même pas écrire un
filtre_filtrer_dist() pour inverser le premier et le second argument dans les squelettes ?
Cédric
En fait cette fonction a été introduire par
http://trac.rezo.net/trac/spip/changeset/10948
dans l'unique but de pouvoir prendre en compte pour chaque type MIME un filtre spécifique.
Il y a plus de mille types MIME, aussi il est indispensable de donner un traitement par défaut mais qui va différér selon les 7 familles MIME.
A la réflexion, ce qu'on pourrait faire c'est de définir les 7 filtres par défaut
filtre_text_dist (qui s'appelle actuellement filtre_text_txt_dist ce qui est arbitraire)
filtre_image_dist
filtre_audio_dist
filtre_video_dist
filtre_application_dist
filtre_message_dist
filtre_multipart_dist
Avec ça, on peut supprimer ce 3e arg, du moment qu'on écrit le corps comme ça:
function appliquer_filtre($arg, $filtre) {
$nom = preg_replace('/\W/','_', $filtre);
$f = chercher_filtre($nom)
if (!$f AND $nom!==$filtre) $f = chercher_filtre(preg_replace('/\W.*$/','', $filtre));
return !$f ? '' : $f($arg);
}
Ainsi, quand on envoie text/javascript ça cherche filtre_texte_javascript_dist qui n'existe pas en std (mais pourrait l'être) puis filtre_text_dist qui existe et va typographier correctement la chose (balise PRE et entités html pour < etc).
Cet ajout ne me semble pas interférer avec le pb posé, puisque celui-ci concerne les filtres où la RegExp \W ne trouve rien.
Symétriquement on peut rajouter des arguments, ça ne gênera pas l'appel pour les modèles de documents.
ok ?
Committo,Ergo:Sum
http://trac.rezo.net/trac/spip/changeset/15362
Committo,Ergo:Sum
Ah, je viens de trouver un autre truc.
La notation:
[(#SET{url_lien,})]
(remplir url_lien avec rien) n'est plus acceptée.
Il faut bien mettre des guillemets vides:
[(#SET{url_lien,""})]
A*
Martin Arnaud wrote:
Ah, je viens de trouver un autre truc.
Et ailleurs (http://permalink.gmane.org/gmane.comp.web.spip.devel/56762), je
vois que le double pipe derrière #LOGO n'est non seulement plus nécessaire
mais aussi déprécié. Tant mieux. Mais c'est une incompatibilité (ou alors
déprécié veut dire "marche encore mais ne plus utiliser" ?)
Dans le même ordre d'idée, reduire_image ne passait plus il y a quelques
jours. A mon avis, c'est pas forcément à corriger (si ce n'est déjà fait...)
vu le temps qui est passé depuis l'adoption de image_reduire. Mais cela
fera(it) une incompatibilité.
"marche encore" bien sûr.
mais ne plus utiliser...
Pas doué, j'ai mis à jour en 2.1-rc mon bon gros site pro sans le faire exprès (je croyais passer en 2.0.10). Celui que je me gardais pour un long week-end. Avec quelque dizaines de milliers d'images et des vieux plugins bien crados.
Hé bé le passage de 2.0.9 en 2.1-rc s'est étonnement bien passée!
Quelques remarques:
- j'avais deux vieux plugins qui contenaient <fonctions></fonctions vide dans plugin.xml. Ça n'est plus accepté.
- j'ai la mention «Installation du plugin... Echec» sur plusieurs plugins, mais ils fonctionnent parfaitement par ailleurs.
- reduire_image n'est plus accepté. (Je ne sais plus si je l'avais déjà dans la liste.)
Arnaud