NYCPHP Meetup

[Hans Zaunere]

David Mintz wrote:

> On Wed, 12 Nov 2003, Michael Southwell wrote:
> 
> 
>>What settings do you consider essential?  How should they be set, and why?
> 
> 
> This is pretty obvious, but since we're talking Phundamentals, it bears
> pointing out that the php.ini settings that cannot be overridden at
> runtime with ini_set() or via .htaccess probably merit special
> consideration, since you can't change them without editing php.ini and
> restarting apache.

To backtrack a bit...

A lot of the replies to this last PHundamentals thread was in regards to the act of setting the ini settings.  Going back over my mailbox and seeing the wording we chose, "How should they be set..." I can see the confusion.

That was next month's topic :)  This month was to be a seeding of what ini settings are important to keep in mind, and what values they should have.  So, here's my 2 cents, albeit a dollar short and a day late:

In simple terms, compare the recommended php.ini and the standard php.ini that come with every PHP distribution.

http://cvs.php.net/cvs.php/php-src/php.ini-dist?login=2
http://cvs.php.net/cvs.php/php-src/php.ini-recommended?login=2

Those that have a stricter setting in the recommended version should be kept in mind :)

When I set up a new environment, production or development, I generally just drop php.ini-recommended into place (named as php.ini of course) and things are happy.  The directives noted at the top of the recommended php.ini are most crucial, with these additional notes:

register_globals:  NO!  OFF!!

display_errors:    On if it's a very big site and you're in development mode.

log_errors:        Always on, production or dev

output_buffering:  This is one of the few directives I will sometimes tweak, even when using the php.ini-recommended.  While buffering can be great, it can sometimes cause a lot of confusing and subtle bugs.  I'll typically turn this off, especially during development.

magic_quote_gpc:   This is up there with register_globals, IMO.  Having stuff do a lot of automatic stuff for you generally isn't good.  Keep this off, always.

error_reporting:   This is a big one; E_ALL is good.  With log_errors and display_errors on, in development, you can watch your site work perfectly, without even a warning.  Then when it goes it to production, flip display_errors off and you're golden.  Coding to E_ALL error standards can also help trace bugs, or even catch intrusion.  If a lot of warning about undefined variables come up, either there's a bug in the call to that script, or someone is where they aren't supposed to be.


There are some others, not even considering the safe_mode, session, and more specialized ini settings.


max_execution_time:  I personally think 30 is too high on trafficed sites.  If you know you're not doing any heavy calculations, bring this down and save a Denial of Service attack.

max_input_time:  Same here.  DoS friendly.

include_path:       can often be a critical setting, of course


Viva php.ini-recommended!

H