$_GET ne décode plus l'URL

WRInaute impliqué
Bonsoir à tous,

J'ai un site où je passe des variables dans l'URL que je récupère dans une autre page avec $_GET, et tout se passait bien.

Mais j'ai déménagé le site chez un autre hebergeur, et mes variables sont devenues encodée comme dans l'url , avec des % etc..
Ce qui est pas très joli pour faire des : echo $mavariable
J'ai bricolé avec des:
htmlspecialchars (urldecode ( $MavariableRecupérée ))

et tout va bien désormais.

Pourquoi le $_GET ne décode plus ?

Les 2 hebergeurs ont php 5

Merci si vous avez une idée !
 
WRInaute impliqué
Merci, c'est ce que je pensais,

Dans l'ancien hebergement, register_globals etait à off.register_argc_argv aussi à off.
C'était les différences, enfin celles que j'ai vu, il y en a surement d'autres!.

Chez le nouvel hebergeur, le register_globals est à on par défaut et le register_argc_argv, aussi est à on

Hier je les ai mis à off avec le htaccess, et dans le php info, register globals s'est bien mis à off .
Mais pas register_argc_argv.

Et ce soir, surprise, meme enlevant les urldecode, ca fonctionne !! . Pour l'instant je laisse quand meme le urldecode ! .

Et dans phpinfo register_argc_argv s'est mis enfin à off ! , peut-être un reboot d'apache l'a pris en compte ?
Le fait que ca remarche , est-ce lié au register_argc_argv ?

Ou bien à un autre mystère, bienveillant celui là ?
 
WRInaute occasionnel
Et le temps que tu reprennes tout tes script, tu peux placer ce bout de code en haut de tes pages... Ca fera passer le parametre d'url.
Code:
foreach( $_REQUEST as $e => $f )
{
    $$e = $f;
}
 
WRInaute impliqué
Et le temps que tu reprennes tout tes script, tu peux placer ce bout de code en haut de tes pages... Ca fera passer le parametre d'url.

Code: Tout sélectionner
Code:
    foreach( $_REQUEST as $e => $f )
    {
        $$e = $f;
    }

À ne surtout pas faire !!
Il n'y a rien de mieux pour pourrir un code avec des variables inattendues.

En plus, il aurait été judicieux d'utiliser extract.

(dire que j'ai cliqué sur RECO de son poste sans le faire exprès :D)
 
WRInaute occasionnel
J'ai bien précisé que c'est du temporaire le temps de reprendre le code.

Tu ne vas pas mettre le site offline... Faut parfois stopper avec la parano... :roll: Son site, c'est pas non plus celui-du pentagone...
 
WRInaute impliqué
Julia41 a dit:
Le URL décode me semble bien crade en tout cas.

Ou bien à un autre mystère, bienveillant celui là ?
Si ton register_global passe de Off à On, je dirais malveillant ;)

Non, il est à On par défaut, (c'est un VDS, et j'ai un site qui en a besoin) , mais pas de souci pour le mettre à Off par htaccess sur les autres !

C'est sûr que c'est du bricolage le URL décode ! , mais la rustine m'a permis tout de suite que le site soit toujours joli pour le visiteur !.
 
WRInaute impliqué
Ehplod a dit:
J'ai bien précisé que c'est du temporaire le temps de reprendre le code.

Tu ne vas pas mettre le site offline... Faut parfois stopper avec la parano... :roll: Son site, c'est pas non plus celui-du pentagone...


Merci du tuyau en tout cas. Il me servira peut-être !

C'est vrai que la priorité était que le site soit toujours opérationnel. Mais je m'étais débrouillé avec URL decode.

En fait ma question est , est ce que le fait de mettre à off le register_argc_argv a pu remettre le décodage d'URL en place par le $_GET ?, ou bien le register_argc_argv n'a rien à voir, et il s'est passé autre chose ?
 
WRInaute passionné
D'après PHP.net *oui* il faut que ça soit à On ;)

register_argc_argv boolean
Dit à PHP s'il doit déclarer ou non les variables argv et argc (qui contiendront les informations GET). Voir aussi les lignes de commande. Cette directive a été introduite depuis PHP 4.0.0 et valait toujours "on" avant.
C'est toujours à ON sauf cas extrêmement rare.
Je me vois mal faire un site 100% en post, mais ça existe par exemple pour des serveurs d'API.
 
Haut