Des nouveaux commits ont été faits dans la fiche 539
Pour tester/intégrer les modifications avant la prochaine version et en partant de la 1ère modification décrite si dessous:
Remplacer la fonction script_basename dans le fichier /include/functions.inc.php (juste avant le ?>) par
/** * Return basename of the current script * Lower case convertion is applied on return value * Return value is without file extention ".php" * * @param void * * @return script basename */ function script_basename() { if (!empty($_SERVER['SCRIPT_NAME'])) { $file_name = $_SERVER['SCRIPT_NAME']; } else if (!empty($_SERVER['SCRIPT_FILENAME'])) { $file_name = $_SERVER['SCRIPT_FILENAME']; } else { $file_name = ''; } // $_SERVER return lower string following var and systems return basename(strtolower($file_name), '.php'); }
Dans les fichiers
/include/common.inc.php,
/include/functions_calendar.inc.php,
/include/section_init.inc.php
A chaque endroit, où il y a script_basename(), supprimer le '.php' des chaines comparées:
if ($user['is_the_guest'] and !$conf['guest_access'] and !in_array( script_basename(), // Array of basename without file extention array('identification', 'password', 'register' ) ) )
(script_basename() == 'picture')
Je viens aussi de me rendre compte que dans /include/common.inc.php, il faut remplacer:
if ( basename($_SERVER["SCRIPT_FILENAME"]) != 'identification.php' and !is_admin() )
par
if ( script_basename() != 'identification' and !is_admin() )
[HS]Un bon réveillon à toi aussi Rub... Les voeux pour 2007 devront attendre encore quelques heures.
8-)
[HS]
Le problème devrait être résolu avec les commits décrits dans la fiche 539
Pour tester/intégrer les modifications avant la prochaine version:
Ajouter la fonction suivante dans le fichier /include/functions.inc.php (juste avant le ?>)
/** * Return basename of the current script * Return value are chnage to loawer case * * @param void * * @return script basename */ function script_basename() { if (!empty($_SERVER['SCRIPT_NAME'])) { $file_name = $_SERVER['SCRIPT_NAME']; } else if (!empty($_SERVER['PHP_SELF'])) { $file_name = $_SERVER['PHP_SELF']; } else if (!empty($_SERVER['SCRIPT_FILENAME'])) { $file_name = $_SERVER['SCRIPT_FILENAME']; } else if (!empty($_SERVER['PATH_TRANSLATED'])) { $file_name = $_SERVER['PATH_TRANSLATED']; } else { $file_name = ''; } // $_SERVER return lower string following var ans systems return basename(strtolower($file_name)); }
Dans les fichiers
/include/common.inc.php,
/include/functions_calendar.inc.php,
/include/section_init.inc.php
Remplacer partout
basename($_SERVER['SCRIPT_FILENAME'])
par
script_basename()
Sur ce, une bonne année 2007 à tous!
bugtracker a écrit:
Merci à strotti et VDigital pour leurs tests.
La casse n'est pas la même suivant les systèmes (et les variables aussi en passant).
J'ai mis à jour le fichier test_IIS.php pour de nouveau tests.
Merci bien! ;-)
Salut Rub,
je t'ai envoyé un mail avec les résultats des tests.
Bàt
IIS est dispo sur toute machine équipée d'un windows XP Professionnel (et pas Home)...
Certains en ont donc p-ê au boulot, même si ce n'est pas forcément autorisé ...
Pour corriger tous les $_SERVER['SCRIPT_FILENAME'], 2 solutions me viennent à l'esprit: 1 Affectation d'une valeur à $_SERVER['SCRIPT_FILENAME'] si elle est vide (Solution de elguaro mais en effectuant des tests sur les variables de substitutions ou en utilisant $_SERVER['PHP_SELF']) 2 Gestion interne d'un variable pour chaque .php
1
Avantages:
Transparent au niveau du code
Peut-être appliqué à d'autres variables $_SERVER
Inconvénients:
Ne fonctionnera pas forcément sur tous les environnements
Un serveur IIS de test est nécessaire
2
Avantages:
Plus de contraintes d'environnement
Inconvénients:
Modification mineure de l'ensemble des pages
Résout que $_SERVER['SCRIPT_FILENAME']
VDigital a écrit:
[HS]
Si un hébergeur veut nous offrir un espace IIS gratuit pour des tests...
[/HS]
C'est ce qu'on appelle un message croisé ;-)
rvelices a écrit:
D'apres ce que je sache aucun d'entre nous utilise IIS pour developper.
Et ca ne risque pas d'arriver car il n'y a pas de version non payante, à ce qu'il me semble.
Par contre, si l'équipe de dev avait à disposition par un tierce personne d'un environnement de test sur un config IIS, ca pourrait être utile.
rvelices a écrit:
La solution proposee peut marcher sous IIS et pour certaines configuraitons d'Apache, mais j'ai en tete au moins une configuration ou ca ne fonctionne pas.
On peut aussi passer par une solution sans utilisation $_SERVER?
Mais ca ne résoudra pas les autres utilisations de $_SERVER (s'il y en a!).
Merci, rvelices, c'est bien ce que je craignais.
8-)
[HS]
IIS n'est pas utilisé pour développer, c'est un peu normal: mise en oeuvre, sécurité, coût.
Je ne peux que vérifier ponctuellement.
Je n'ai pas l'espace IIS nécessaire pour monter une version de PWG pour faire des simples tests.
Si un hébergeur veut nous offrir un espace IIS gratuit pour des tests...
8-)
[/HS]
VDigital a écrit:
Mais le bug 529 est suivi comme tous les autres.
Et tu as raison de faire un petit up de temps en temps et surtout avant la prochaine sortie d'une version.
Car entre chaque version, on n'a pas le temps de traiter toutes les fiches et le choix est parfois abitraire.
En tout cas, tu as reéouvert le "débat" ;-)
D'apres ce que je sache aucun d'entre nous utilise IIS pour developper.
La solution proposee peut marcher sous IIS et pour certaines configuraitons d'Apache, mais j'ai en tete au moins une configuration ou ca ne fonctionne pas.
Merci pour votre réponse.
Bonnes fêtes.
C'est la solution pour vous très bien.
Il faut qu'on essaie cette configuration sur d'autres serveurs.
Les variables systèmes ne répondent pas toujours de la même façon suivant les environnements.
Il ne faudrait pas en solutionnant votre problème que nous placions d'autres utilisateurs de PWG devant un autre problème.
Mais le bug 529 est suivi comme tous les autres.
(Rub fait un travail énorme dans le suivi par exemple).
8-)