Maarten wrote at 9/28/2009 2:44 am:good one, been planning a blog posting like this one for ages but it hasn’t been done yet. Will take yours now and mostly translate it into dutch if you don’t mind?
| « Pair Programming: Where Teamwork Comes Out | Reviewing A Book » |
When setting up a web server with PHP, there are a number of settings that are critical to consider. PHP 5.3 contains both a development INI file and a production INI file; however, users of older PHP releases (or those who don’t have direct control over their INI files) will want to pay attention and make sure that certain settings are configured.
These settings are the settings that I use whenever I configure a PHP server.
register_globals = Off A holdover from ancient PHP versions, this setting is by default turned off and should remain that way. Even though it is disabled by default, many hosts enable it to continue supporting legacy code; in your own code, I recommend you set it to off. You can turn it off on a directory basis using htaccess files.
magic_quotes_gpc = Off This is another old holdover from PHP, and is slated for removal in PHP 6, along with register_globals. This automatically adds slashes to all GET, POST and COOKIE data, meaning that a posted string of “This is my code’s string” gets converted to “This is my code\’s string”. magic_quotes_gpc offers NO security; you should turn it off. It can be turned off per directory.
error_reporting = E_ALL | E_STRICT This is the strictest error setting you can insist on from PHP. Some people will disagree with the E_STRICT statement; I think that it’s important that our code conform to high code standards, and that means having E_STRICT turned on. This should be done even on production, because you want to know about errors you’re getting from your code, even if you didn’t see them during testing.
display_errors = Off Even though we want to have PHP raise errors, we don’t want them displayed to the end user! Turn display_errors to off and log the errors instead. You can configure the log path in each directory, and you should make use of this feature. Displaying errors to the end user is a security vulnerability, because it allows them to determine the operating system and file structure of your application.
session.gc_maxlifetime = 28800 This setting is how long a session is valid on your system. The default length of time is a paltry 1140 seconds, or 24 minutes. That means that someone reading a long article behind a login portal might get logged out after they’re finished. The setting I use is 8 hours, which is enough time for most users. You can also use four hours (14,400 seconds).
short_open_tag = 0 This is on by default, but using short tags (<?) is bad form. Turn it off and don’t utilize it. (Edit) There are two reasons for this. First, and the more rare reason, is that it could create problems with XML parsing. If you ever have the need to embed PHP in XML (as I did once), you may run into this. This is rare, but possibe. Second, and more common, is that if you ever change hosts, or start using a host that configures PHP for you, they may disable the short tags by default. This could leave you scrambling for a fix for your code. Changing 20,000 <? into <?php can take a long time (I’ve done it; it can be a pain).
upload_max_filesize = 10M & post_max_size = 11M If you do anything with file uploads, you’ll find that the default 2 MB is woefully inadequate. I set mine to at least 10 MB, to ensure that most files I want are uploaded. You’ll also want to up the post_max_size due to the fact that it is set to a default of 8 MB, which will cause your file upload to break.
How to Set PHP Directives In htaccess Files
Finally, a discussion of how to set these values: if you make use of a shared host, you won’t be able to get direct access to the php.ini file. There are two different htaccess directives you need to be aware of: php_flag and php_value. The use of php_flag is reserved for boolean values, like register_globals and magic_quotes_gpc. You use php_value for things that are not boolean, like error_reporting and error_log.
For example, the syntax for turning off register_globals is as follows:
The syntax to set the error log file path is as follows:
This blog entry implements The Beginner Pattern.
Brandon Savage is the author of Mastering Object Oriented PHP and Practical Design Patterns in PHP
Posted on 9/28/2009 at 1:00 am
good one, been planning a blog posting like this one for ages but it hasn’t been done yet. Will take yours now and mostly translate it into dutch if you don’t mind?
David wrote at 9/28/2009 3:27 am:
Setting PHP directives in .htaccess files only works with mod_php, which a lot of hosts don’t use because of security issues. If you’re using cgi/fcgi, you’ll need to have a custom php.ini file on a per directory basis.
Good write-up though. I was a bit surprised by the gc_maxlifetime value you use, but I guess it depends on your application.
Markus Wolff wrote at 9/28/2009 3:56 am:
Hey Brandon, while I greatly respect you and applaud you taking the time to write entries targeted at beginners to help them out, I have two gripes with this one, both regarding the advice on short_open_tag:
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 ;-)
kodegeek (@kode_geek) wrote at 9/28/2009 5:55 am:
Three more things i want to reffer to enable them
mod_rewrite module to ON
php curl extension to ON
php gd2 extension to Onas 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!
Brandon Savage (@brandonsavage) wrote at 9/28/2009 6:12 am:
Maarten, the license I use allows for translation or reuse with attribution. It prohibits commercial use.
Hey Markus, thanks for your thoughts.
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. :-)
Shaun (@farrelley) wrote at 9/28/2009 7:53 am:
I would also recommend that you keep display_startup_errors to 0 in production but to 1 in development
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
Taco (@takkie_nl) wrote at 9/28/2009 9:35 am:
Hey Brandon,
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.
Taco, that’s a fair point. My only counter would be that if you’re exceedingly vigilant about having things like post-commit hooks and QA teams, you can generally avoid a slip-up like that from ending up on production.
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
Aren’t short tags being removed in PHP6 though? Or is that not confirmed yet?
The PHP manual doesn’t indicate that they are deprecated. However, the PHP manual DOES indicate that they are not suggested for use (which is why I wrote about them here).
Needless to say we do have commit hooks preventing us committing short open tags ;)
Samuel Folkes (@SamuelFolkes) wrote at 9/29/2009 4:05 pm:
RE: the short_open_tag setting, I have never ever heard a GOOD reason for using short_open_tags. Taco’s argument for leaving them enabled in php.ini is a fairly good one. However, enforcing coding standards with your team pretty much rids you of that problem. Three extra characters i’m sure won’t kill anyone.
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.
P.S. Loving The Beginner Pattern series Brandon ;)
pgl (@pgl) wrote at 12/10/2009 9:40 am:
“magic_quotes_gpc offers NO security” – well, no, that’s not true. It does. It’s just not enough to rely on.
Also, IMO: it’s disingenuous, in an article about modifying php.ini settings, to suggest that a reason for turning off short_tags is that you might one day move to a host where you can’t _modify php.ini settings_.
| « Pair Programming: Where Teamwork Comes Out | Reviewing A Book » |