Les directives INI, c'est le mal !

14 avril 2016php, configuration, ini
 Cet article a été rédigé il y a plusieurs années et peut ne plus être tout à fait à jour…

This post is also available in English.

Plusieurs fois, alors que des évolutions étaient discutées pour PHP 7, j’ai assisté à des échanges où un intervenant proposait de rendre optionnelle une nouvelle fonctionnalité1, par le biais d’une directive de configuration INI – l’idée étant que chacun pourrait alors l’activer ou non.

Mais le principe même de directives permettant de changer, parfois en profondeur, le comportement d’un langage de programmation… J’en ai des frissons !


Imaginez un langage2 créé pour faciliter la mise en place de formulaires HTML et le traitement des données saisies.

Pour aider les débutants n’ayant aucune notion de sécurité, et puisque l’utilisation de MySQL pour le stockage de données est à la mode, les développeurs de ce langage mettent en place une option qui, une fois activée, entraine l’ajout automatique d’un \ devant tous les guillemets ' arrivant en entrée0.

Bien sûr, une partie des administrateurs système active immédiatement cette directive, puisqu’elle améliore considérablement la sécurité3 en empêchant certaines injections SQL. Mais d’autres administrateurs la désactivent, puisque c’est à chaque développeur de savoir gérer ses données : le langage ne doit pas les modifier à la volée !

Et là, une application donnée fonctionnera parfaitement sur un serveur, alors qu’elle fera n’importe quoi sur un autre – soit en injectant des \ partout, soit en explosant violemment sur la moitié de ses requêtes SQL ! Elle n’aura en effet pas été spécifiquement développée pour tenir compte des différentes combinaisons d’options de configurations.

Vous en rêviez ? Bienvenue dans l’enfer des magic quotes4 !

Dans le même genre, vous vous souvenez de register_globals, où des variables apparaissaient par magie dans vos scripts, pour peu que cette directive soit activée ? C’était d’enfer !


Revenons à une période un peu plus proche : chaque fois qu’une directive de configuration est ajoutée à PHP5, cela signifie :

  • Plusieurs branches de code à tester, déboguer, maintenir. La maintenance d’une fonctionnalité introduite dans un langage aussi répandu que PHP, c’est sur 10 ans. Et plus !
  • Plus de documentation à rédiger, d’une part – et à lire et à comprendre, d’autre part.
  • Plus de travail à fournir pour s’assurer que chaque application6 fonctionne avec chaque combinaison de paramètres.
  • En cas de problème, combien de temps avant de réaliser qu’un comportement étrange est dû à une valeur inhabituelle ou inattendue pour une directive de configuration bien spécifique ? Ou, pire, à une combinaison inhabituelle de valeurs pour quelques directives de configuration tordues ?

Heureusement, les développeurs qui travaillent sur PHP sont conscients de ces problèmes et limitent donc autant que possible les ajouts de nouvelles directives INI. Ils fournissent également deux fichiers php.ini-development et php.ini-production, qui contiennent des valeurs assez appropriées, dont il est bon de rester proche.


Quoi qu’il en soit, avant de suggérer « mais ils pourraient permettre d’activer ou non cette fonctionnalité via une simple directive INI » pour des points aussi critiques qu’un système de typage souple ou strict, demandez-vous si vous souhaitez véritablement arriver à deux langages se comportant de manière complètement différente, avec des applications et bibliothèques fonctionnant uniquement sur certaines combinaisons de configurations et pas d’autres…

Et maintenant, répétez après moi : « les directives INI, c’est le mal ! »



  1. Parce qu’elle risquait de casser la compatibilité antérieure, parce qu’elle changeait certains aspects de la façon d’être du langage, parce qu’elle n’était pas appréciée par tous, parce que certains n’en voulaient pas… [return]
  2. Je vous laisse deviner à quel langage je peux penser ^^. Mais mes propos, quitte à les généraliser un peu, s’appliquent pour de nombreux autres ! [return]
  3. Ou pas (tellement ?), en fait… [return]
  4. PHP visant à réduire au maximum les ruptures de compatibilité, il a fallu des années avant d’être enfin débarrassé de cette mauvaise-bonne idée – et des différences de configurations et de comportements allant avec ! [return]
  5. C’est vrai également pour à peu près n’importe quel logiciel, d’ailleurs ;-) [return]
  6. En particulier, pour les logiciels, open-source ou non, distribués pour être installés sur différents serveurs gérés par des administrateurs aux pratiques différentes. [return]