Reprise du message précédent :

Qu'importe, on va bien rigoler par ce que les hébergeurs pourront plus activer register_global et que du coup tous les mauvais programmeurs pleureront partout sur internet.
Ca va être la joie et la bonne humeur dans les chaumières .... et pleins de boulot pour les pros.  

Comme tu dis, t'as essayé une bidouille proposé par ton hébergeur.

oui mais là j'ai le même htaccess qu'avant, et çà marche plus... C'est moche

il y a aussi l'historique
 
passer d'un site qui utilise register_global, les HTTP_POST_VARs , .... a un truc a peu pret correct m'a occupé 6 mois, sans faire de nouvelles fonctionnalité, juste pour maintenir l'existant

Ca représentait combien de lignes de code grosso modo?

avant refactoring: environ 120 000 lignes de code ( comptées avec sloccount)  
maintenant, un poil plus de 60 000 lignes, et il y a encore un peu de gras à enlever sur certains modules ( cible a 50 000 lignes avec plus de fonctionnalités )  
 

ok, donc tu t'es pas contenté d'un simple "$HTTP_POST_VARS => $_POST" + déclaration des variables non déclaré.
Tant de boulot en 6 mois, je trouve que c'est vraiment pas mal ... ou que ton prédécesseur étant vraiment très nul et qu'il faisait en 15 lignes ce qui se fait en une.

c'etait un code  qui datait de 2003 pour la base, le reste a été branché avec plus ou moins de succès dessus, suivant le niveau des intervenants  
 
donc refactoring global, passage en mvc, à l'objet  suppression des doublons, des fichiers .bak ( qui était quand meme utilisé ) , j'en apsse et des meilleurs

Justement, j'adore les meilleurs. C'est là qu'on rigole.

au début, oui , mais au bout de quelques mois, ça lasse de se taper des ficheirs de 2300 lignes , sans fonctions,  et avec un switch de plus de 1500 lignes

exemple sur les premières lignes d'un fichier  

<?
     $voir_html=1;
     
     include $cfg_chemin_api.'classes/wysiwyg/editor.textarea.php';
     
      // on recupere les groupes restreints par groupe si jamais on a besoin
     $tmpAryGroupesRestreints = retourne_groupes_restreints_dossier();
     
    $dossier=$sesNavigation[dossier][id];
    $sql = " SELECT * FROM masques a, masques_droits b WHERE b.id_dossier='$dossier' ";
    $sql.= " AND (b.id_masque=a.id ";
    $sql.= " )  AND b.associer='1' GROUP BY a.id";
    $res = mysql_query($sql, $bdd);
    //echo $sql;
    $nb_masques=mysql_num_rows($res);
    if($sesNavigation['section']=="pages_unique" || $sesNavigation['section']=="navigation" )
    $nb_masques+=2; // car on ajoute le masque import html et le masque page de garde

$voir_html, $cfg_chemin_api,$bdd sont des variables globales
 sesNavigation fait reference a $_SESSION['sesNavigation'] , et a été chargée par $_GET['dossier'] par un fichier inclus un eu plus en amont dans la chaine, sans contrôle
pas de sécurisation  au niveau de la requête
en cas d'erreur de la requête, on continue, c'est pas grave , on utilise quand même mysql_num_rows
....

et ça continue avec un WTF toutes les lignes pendant plusieurs centaines de ligens. Par exemple $id est une variable globale, il est donc interdit de l'utiliser dans un paramètre , sous peine de voir arriver des effets de bords sympa

Rien qu'avec ça, je me marre. Une gestion des droits qui prend un "masque de droit" au hasard parmi ceux qui sont rattaché à un "masque" donné.
Rien que ça ça donne une idée de la qualité du code qui tourne autour.
 
 
  Je l'avais manqué celle là.

Je suppose que ça marche en error-reporting: rien, la constante est remplacée par sa valeur en chaine

met un coup de E_STRICT sur un code qui est tout comme ça et admire le résultat. C'est lolilol comme page.

Là est toute la logique de PHP :
Attention c'est pas bien    mais çà marche

héla malheureux, un code comme ça, tu active aucun reporting ( déjà qu'en l'activant pas il y a des messages qui te petent quand meme a la gueule)  

c'est le quasiment le cas maintenant :  
E_ALL sur le dev
E_ERROR vers log sur le prod

Ca me rappelle un CMS que j'ai essayé il y a quelques mois. Pleins d'erreur dès que je mettais un petit E_ALL mais les seules erreurs qui n'étaient jamais remonté c'était celles qui sont cruciales : classiquement les "aie, la fonction mysql_query n'existe pas" qui te bloquent dès l'installation par une belle page blanche vu qu'ils sont allé foutre un @ dessus.

nan    
 

sisi

Ce serait pas exactement ce que je disais ça ?

Oh oui c'est horrible ça, ça arrive sur 1 machine sur 3, et 1 fois sur 4 même avec tout ce qu'il faut Bon on peut noter que j'ai pas cherché 4 heures une solution. (mais je laisse en E_STRICT )

Sinon pourquoi vous mettez pas de E_ALL en prod

Tu as lu le php.ini? La réponse est dedans il me semble.

Non, donc oui, et non ya rien là dessus dedans apparemment

par contre ya ça :

Pose toi alors la question: as-tu envie que tes utilisateurs se tapent un message qui va leur faire peur et jeter le discrédit sur ton site, ou tu vas gérer ça en homme et leur afficher une page plus user-friendly?

Bien sûr que non, c'est pour cela que je vais te faire découvrir le concept de log

T'as pas idée du nombre de logs que j'ai à gérer au boulot

J'espère pour toi oui

Mais pourquoi afficher les erreurs en prod, donc ?

edit : ah nan en fait la réponse est dans ton post, ok mais c'est un peu une raison pas top, si ?

Chépas, voir un fatal error ou autre message du même calibre en prod, en tant que développeur, ça me file l'urticaire. Et en tant qu'utilisateur, la première fois c'est rigolo, mais plus après.

Je comprend rien

Si t'as une couille en prod, t'as pas un log qui récupère les erreurs ? et si oui pourquoi ne pas y incorporer les notices au même titre que les fatal ou les errors ?

T'as pas de log parce que t'as peur d'aller le regarder et de découvrir des erreurs, alors tu laisse le client découvrir juste les grosses, c'est ça ou j'ai vraiment rien capté ?

c'est pour ça que tu le vois pas, il va dans un fichier log.

J'ai jamais dit que j'enregistrais pas mes erreurs dans un log

Bon bah on a tous rien compris à ce que tu avances alors

Laisser une stacktrace s'afficher en prod = bad. C'est plus clair?

Bah oui, c'est pour ça qu'on met non seulement un log, mais aussi un display_errors=off. Comme ça rien ne s'affiche au client et dans le log on a tout, y compris les notices.

Non ?

Vi, exactement. Il a justement fallu que je déplace nos sorties dirigées vers le Windows Event Log à une table dédiée. L'astuce étant qu'on n'a pas un accès direct aux serveurs de prod et que pour demander une copie du log, c'est relou. Et je suis pas peu fier du résultat.
 
Mise en prod dimanche soir

Oh mon dieu, un projet fini 6 jours *avant* la date de mise en prod

La date de prod doit être une date en 2008. C'est pas logique ce que tu dis là