Another bothersome php.ini setting is safe_mode. I’ve had many complaints about a WordPress plugin I wrote not functioning correctly only to find on investigation that safe_mode was set to ON on the server in question and was causing conflicts with cURL. I think that’s another setting we should set to off in order to avoid weird errors popping up. Its deprecated in PHP 5.3 and set to be removed altogether from PHP 6.0.

I like PHP CodeSniffer. Matthew Turland does a great job of explaining how to create these hooks: http://blueparabola.com/blog/subversion-commit-hooks-php

Regarding the short open tag: I’d let people decide for themselves whether or not to use it (not everyone needs to be able to run their code on a different server). But even if someone decides to only use the ‘long’ tag (like our team does) I’d still encourage them to set the short_open_tag setting _on_ on production servers and off on development servers.

This will ensure that when you accidentally upload code with a short open tag (i.e. third party code or a typo) it will not be served as html and thus be visible to visitors.

display_startup_errors – Even when display_errors is on, errors that occur during PHP’s startup sequence are not displayed. It’s strongly recommended to keep display_startup_errors off, except for debugging.

Another good post would be to show the .ini directives (PHP_INI_PERDIR, PHP_INI_ALL, PHP_INI_SYSTEM) @
http://ie.php.net/manual/en/ini.list.php

The reason that I suggested the user turn off the short tags has more to do with shrinking the toolbag. I’ve actually run into the short tag issue with XML (I had to have PHP parsed in a .xml file once and I spent hours fighting with it). By simply advising them to turn it off, if they do, they won’t be tempted to use it later because it won’t be available to them.

There are lots of people that stand by the short tag. I see their reasons, and I don’t think they’re necessarily bad for it. However, the biggest reason why I think this is a bad idea is that it creates a portability problem: if another host disables short tags, their code won’t work. Trust me, I’ve experienced this too.

I’ll add more of an explanation so as to not be so patronizing. Hope that helps explain more of my thinking. :-)

as they are frequently used. I don’t agree with you about to turn off short open tag although it is highly recommended not to use that tag.

Thanks for the nice post!

1. you say it’s bad form to use it, and advise to just turn it off and leave it that way. IMHO, that’s bad form by itself: You are effectively patronizing the reader by just telling them what they should not do, but you don’t provide any explanation.

2. that said, I’d be interested in your explanation on that one – can you provide a real-world example, something that may actually be found in the wild, where short open tags are a bad idea? Most people tend to argue about breaking XML validation, but I have never, ever encountered anyone actually trying to parse or validate XML with embedded PHP in it. Whenever someone actually embeds PHP within XML, the file is usually run through PHP first and the XML parser will get the generated content. So IMHO this argument is invalid because 99% of all users will never want to use XML this way and it is silly to have all PHP developers clutter their templates with “<?php echo …" where a "<?=" would suffice, just so that the (probably even less than) 1% of the XML purity zealots are happy.

Just my $0.02 ;-)

Good write-up though. I was a bit surprised by the gc_maxlifetime value you use, but I guess it depends on your application.