Almost every public CMS out there uses a .php configuration file for the database settings and so on. For example WordPress automatically creates a .php config file when you install it.
Why don't they just use a .ini file? PHP already has parse_ini_file() and I'm sure other languages have similar functions.
With PHP in particular; the difference between an .ini file and a .conf.php file is negligible.
Using PHP directly for configuration has the distinct advantage of only needing to relate to one well-defined, portable syntax for configuration, and the fact that the configuration file is properly code is occasionally useful.
Compared to that; an ini file has little to nothing to offer; and include, require and require_once are all well-known and (mostly) well understood.
relate to one well-defined, portable syntax for configuration I don't get that. ini files have a well-defined and portable syntax as well. Every .conf.php file has its own structure, most are array based, but that's not so different than an ini file.
.ini files for storing configuration, there would no doubt be lots of misconfigured instances running where the configuration was publicly accessible, which is usually not a good thing. With PHP files, it's going to be very, very rare for a server to be misconfigured to serve the contents of it to a visitor.
Feb 9, 2012 at 4:57
Generally speaking I prefer .ini or XML configuration files. In larger systems, often someone other than the developer will need to change a configuration value, possibly a DBA or a sysadmin. Most DBAs and sysadmins I know wouldn't have any problem navigating through a simple PHP script, but I would prefer if they didn't. One small mistake in there can harm the whole application in quite a few ways.
But in smaller systems, it's extremely convenient to use PHP scripts for configuration. I was playing around with the AWS SDK today, which also uses a PHP script for configuration:
CFCredentials::set(array(
'development' => array(
'key' => 'xxx',
'secret' => 'xxxx',
'default_cache_config' => sys_get_temp_dir(),
'certificate_authority' => true
),
'@default' => 'development'
));
Instead of hardcoding a default_cache_config, I'm passing the system temp, and that would work in every system I deploy the script. This script is a small proof of concept that will be passed around 10 developers, and I want them to run it as is, withouth having much to think about. If the prototype evolves, I'll hardwire it with my XML configuration class (and obviously won't rely on filesystem cache).
The answer is simple: a conf.php has basically zero work required for it to operate. It's just another source file.
Speed without caching can also be the reason. PHP config can be opcode-cached transparently if needed. Whereas INI file needs to be text-parsed every time it's read and you need to create the cache yourself. For small files it's ok, but with hundreds of lines parsed on every request it can raise to tens of miliseconds, which is quite a lot for 200ms optimized web.
