The new .htaccess file for PHP coming soon!

Per-user php.ini on the horizon

[coopster]

Has anybody else been watching the changes coming in PHP 6? I know many of us have recognized that the developers are cleaning up quite a few things and getting rid of some old configuration directives. However, it also looks as if it's predecessor PHP 5.3 is paving the way [news.php.net] for more flexibility between shared hosting providers and per-user configurations:

1. Added ".htaccess" style user-defined php.ini files support for CGI/FastCGI.
   
2. Added support for special [PATH=/opt/httpd/www.example.com/] sections in php.ini. All directives set in these sections will not be able to be overridden in user-defined ini-files or during runtime in the specified path.
   
3. Improved php.ini handling:
   
   • Added better error reporting for syntax errors in php.ini files
     
   • Allowed "ini-variables" to be used almost everywhere ini php.ini files
     
   • Allowed using alphanumeric/variable indexes in "array" ini options
     
   • Fixed get_cfg_var() to be able to return "array" ini options
     

+;;;;;;;;;;;;;;;;;;;; 
+; php.ini Options ; 
+;;;;;;;;;;;;;;;;;;;; 
+; Name for user-defined php.ini (.htaccess) files. Default is ".user.ini" 
+;user_ini.filename = ".user.ini" 
+ 
+; To disable this feature set this option to empty value 
+;user_ini.filename = 
+ 
+; TTL for user-defined php.ini files (time-to-live) in seconds. Default is 300 seconds (5 minutes) 
+;user_ini.cache_ttl = 300

What benefits do you see here for you?
Do you see any pitfalls?
Security issues, good or bad?

[eelixduppy]

Added support for special [PATH=/opt/httpd/www.example.com/] sections in php.ini. All directives set in these sections will not be able to be overridden in user-defined ini-files or during runtime in the specified path.

I find that pretty neat, actually. This could be useful for many different reasons. A positive here, methinks

Thanks for bring this up, coop. :)

[Receptional Andy]

I like, but making ini options more accessible = worse security. Applause for PHP heading in the right direction, but euuchh, shared servers. What a pain.

[coopster]

Yes, when you are used to full control over your configuration it is difficult to accept what a shared server may have defined as "the way it is" and that's it. Shared servers are set up somewhat limited to cater to the masses while attempting to limit the hosting provider's security exposure. Many, many members here at WebmasterWorld run on shared servers. And if you are doing any type of contract work, sooner or later you are going to provide your services to somebody hosting on a shared server. I'm hoping this path makes it easier for a developer to implement the necessary directives on a per site basis rather than some of the hoops we often have to jump through.