Un de ces sous repertoires (ou site) est protege par un identification au niveau serveur par .htpasswd.
En installant la version 2.1.27 de SPIP, cette identification conduisait a une session existante mais vide:
#SESSION etait toujours renseignee quoique vide et comme j'avais supprime le lien espace prive on ne pouvait rentre dans cette espace qu'en connaissant l'URL.
J'ai decouvert que le probleme venait du fichier /ecrire/inc/session.php qui avait ete modifie par la revision 21818, ligne 22:
$GLOBALS['visiteur_session'] = '';
est devenue:
$GLOBALS['visiteur_session'] = array();
Je precise que j'ai un autre site non mutualise qui est protege par un ..htpasswd et qui n'a pas eu de probleme au passage a la 2.1.27.
J'ai decouvert que le probleme venait du fichier /ecrire/inc/session.php qui avait ete modifie par la revision 21818, ligne 22:
$GLOBALS['visiteur_session'] = '';
est devenue:
$GLOBALS['visiteur_session'] = array();
Je precise que j'ai un autre site non mutualise qui est protege par un ..htpasswd et qui n'a pas eu de probleme au passage a la 2.1.27.
Comme dit dans le log 21818, cette modif a été faite parce que dans d'autres squelettes on considère que #SESSION est toujours un tableau,
on ne peut pas revenir en arrière sans retomber sur les anciens problèmes.
Le pb vient de la compilation de #SESSION qui se rabat sur celle de #ENV qui produit:
Le fait que ce code renvoie tantôt le résultat d'un serialize tantot autre chose ("" ici) est intrinsèquement problématique,
et comme ça ne concerne pas seulement #SESSION mais #ENV, rechanger ce code qui date de 10129 me paraît dangereux.
Je pense que le mieux est que dans la noisette ci-dessus, on remplace "#SESSION|?" par "#SESSION{nom}|?" étant donnée la suite.
#SESSION{nom} a regle le probleme merci, mais il fallait que je garde la condition #SESSION{nom}|? pour afficher soit la bienvenue soit le lien du login.
#SESSION{nom} a regle le probleme merci, mais il fallait que je garde la condition #SESSION{nom}|? pour afficher soit la bienvenue soit le lien du login.
Le lien de login n'apparaissait pas dans le code que tu as donné initialement
(ça sort de quel plugin d'ailleurs ?):
En fait l'écriture (#NOM-DE-BALISE|?{' ',''}) est un hack horrible destiné à contourner les limitations de l'analyseur syntaxique qui ne supporte pas plus de 3 (si je me souviens bien) accolades imbriquées, il faut l'éviter quand il y en a moins de 3 en écrivant directement dans les accolades après "?".
En fait l'écriture (#NOM-DE-BALISE|?{' ',''}) est un hack horrible destiné à contourner les limitations de l'analyseur syntaxique qui ne supporte pas plus de 3 (si je me souviens bien) accolades imbriquées, il faut l'éviter quand il y en a moins de 3 en écrivant directement dans les accolades après "?".
À propos, est-ce que la syntaxe que tu avais proposée à Avignon résoudrait ça aussi ?
J'aimerais bien qu'on reparle sérieusement de cette nouvelle syntaxe.
#SESSION{nom} a regle le probleme merci, mais il fallait que je garde la condition #SESSION{nom}|? pour afficher soit la bienvenue soit le lien du login.
Le lien de login n'apparaissait pas dans le code que tu as donné initialement
(ça sort de quel plugin d'ailleurs ?):
D'un article sur le plugin acces restreint. Le login se trouve dans une autre noisette.
En fait l'écriture (#NOM-DE-BALISE|?{' ',''}) est un hack horrible destiné à contourner les limitations de l'analyseur syntaxique qui ne supporte pas plus de 3 (si je me souviens bien) accolades imbriquées, il faut l'éviter quand il y en a moins de 3 en écrivant directement dans les accolades après "?".
Mon probleme c'est que en utilisant ? comme il faut (?{commande,commade}) je mes chiane de langue ne sont plus interpretees (ou alors j'ai oublie comment faire). de toute facon ca marche aussi bien avec (#SESSION{nom}|oui) et (#SESSION{nom}|non).
Mon probleme c'est que en utilisant ? comme il faut (?{commande,commade}) je mes chiane de langue ne sont plus interpretees (ou alors j'ai oublie comment faire).
Tu me surprends. Je viens de vérifier que ceci par exemple se compile sans pb:
[(#SESSION|?{<:foo|strtoupper:>,<:bar:>})]
de toute facon ca marche aussi bien avec (#SESSION{nom}|oui) et (#SESSION{nom}|non).
Leur problème, ainsi que "|?{' ', ''}", c'est que ça rajoute un espace et ça peut parfois être gênant.
</BOUCLE_alerte> </B_alerte> [(#REM) Barre de navigation, ouverte sur la hierarchie courante On fait un plan, et, quand on avance vers une rubrique, on l’affiche si son parent est expose ou est la racine du site. ]
})] avec cette verion j’ai l’affichage: <:bienvenue:> et le lien du logout n’est pas interprete: <?php%20include_once("./%22 . _DIR_RACINE . « ecrire/balise/url_logout.php »);if ($lang_select = « fr ») $lang_select = lang_select($lang_select)inserer_balise_dynamique(balise_URL_LOGOUT_dyn(
Pour la non interprétation de URL_LOGOUT, comme dit dans le log ça se contourne en écrivant #SESSION** à la place de la première occurrence de #SESSION, il est d'ailleurs recommandé de toujours utiliser ** quand une balise est suivie de "|?" c'est plus efficace et donc ici contourne un bug qui reste à corriger.
<:acces:>