Hi,
Dem stimme ich ja sogar zu. Wenn es um Direktiven geht, die nicht mit ini_set() manipuliert werden können, wird ein kluger Programmierer mit ini_get() Fallunterscheidungen im Steuerfluss einbauen, da er weiß, dass er sich nicht darauf verlassen kann, die Möglichkeit externer Konfigurationsdateien zu haben.
Oder sich diesen zusätzlichen Aufwand sparen, und eine gewisse Konfiguration einfach als Systemvoraussetzung festlegen.
Damit haben wir bereits den ersten konfigurativen Vorfall, wo .user.ini gar nicht genutzt werden kann. Und ich glaube, dass ich mir das Repetieren allein für den Apachen von Direktive AccessFileName und AllowOverride ersparen kann. Jedoch sollte Dir mal langsam klar werden, dass andere Webserver das Konzept verzeichnisweiter Konfigurationsdateien gar nicht kennen.
Ist egal, ob der Webserver das kennt - wenn PHP auf eigene Faust nach einer lokalen Konfigurationsdatei sucht.
Es gibt auch Situationen, in denen du ini_set nicht nutzen kannst.
Richtig. Es ist durchaus denkbar, das jemand ini_set() per disable_functions sperrt; nur betrachte mal die Wahrscheinlichkeit dieser Option gegen das recht sinnvolle Unterbinden von .user.ini-Konfigurationen!
Warum sollte das eine unwahrscheinlicher sein als das andere?
Wenn mir als administrativem Verantwortlichen für eine PHP-Installation die Möglichkeit, dass Nutzer gewisse Konfigurations-Optionen überschreiben, nicht gefällt, dann muss ich dafür sorge tragen, dass dies auf beiden Wegen - per ini_set, oder per verzeichnislokaler Konfigurationsdatei - unterbunden ist. (Das ist kein schwarz-weisses Ja oder Nein, sondern kann für einzelne Optionen durchaus unterschiedlich ausfallen.)
Wenn ich aber entschieden habe, bestimmte Optionen durch den Nutzer überschreiben zu lassen - warum sollte ich das dann nur auf dem einen Wege zulassen, den anderen aber untersagen?
MfG ChrisB
“Whoever best describes the problem is the person most likely to solve the problem.” [Dan Roam]