Author: fil@rezo.net
Date: 2011-01-20 00:07:02 +0100 (jeu, 20 jan 2011)
New Revision: 16987
Log:
modifier de facon plus marginale le prototype de spip_log(), afin d'assurer une meilleure compat ascendante et surtout une utilisation plus simple (seul le cas 'fichier.niveau' est un peu pourri)
spip_log($message,'recherche.'._LOG_DEBUG)
"cette derniere notation est controversee mais le 3eme
parametre est plante pour cause de compat ascendante."
Elément de controverse : Bid@u1!!e de concaténation; pourquoi donc se priver d'un 3ème argument ?
Si il y a un 3ème argument, et que c'est une valeur numérique, est-ce que même avec l'ascendance,
cela peut être autre chose qu'un des niveaux de log ?
spip_log($message,'recherche.'._LOG_DEBUG)
"cette derniere notation est controversee mais le 3eme
parametre est plante pour cause de compat ascendante."
Elément de controverse : Bid@u1!!e de concaténation; pourquoi donc se priver
d'un 3ème argument ?
Si il y a un 3ème argument, et que c'est une valeur numérique, est-ce que
même avec l'ascendance,
cela peut être autre chose qu'un des niveaux de log ?
En SPIP 2.1 cet argument définit le "répertoire des logs". Si donc on
employait spip_log($message, type, niveau) dans un plugin, celui-ci
planterait sous 2.1 en essayant d'écrire le log dans le fichier
niveau/type.log à la racine.
C'est ce que j'imaginais mais le problème semble être
pour les sites en 2.1 qui ont donc la version "avec 3eme parametre répertoire" ancienne mouture de spip_log
MAIS qui utilisent des plugins qui eux utiliseraient un spip_log avec la syntaxe nouvelle mouture.
Une solution pourrait être de créer une nouvelle fonction (j'invente rien...)
et de créer un plugin pour elle seule (ou dans un plugin de compat).
Les plugins et les nouveaux SPIP définiraient cette fonction et l'utiliseraient,
et les anciens SPIP devraient activer ce plugin pour bénéficier des plugins
qui utiliseraient cette nouvelle fonction.
