my_config.ini vs my_config.php

问题:

At work we use a .ini file to set variables prior to calling the rest of the framework (I think it goes

function getConfigVars(){
    //read my_config.ini file
    ....
    //call framework
}

and I have always wondered if there was a benefit to doing it that way.

It seems to me that you then have to write access rules to stop people from looking at it from the web and php has to parse it and understand it.

So, why use my_config.ini rather than my_config.php? It is not like anyone should be touching it after it is set up and it seems more convenient to just call the variables and be able to have your IDE auto complete the text wherever you are using the ini variables / parse it for errors.

回答1:

The Zend Framework contains a config parses that parses files that are written in the ini format (Zend_Config_Ini), it sounds like this is what you are using.

The config file should not be located in your document root, and if it is not in your document root then no re-write rules are required since no-one can access it anyway.

The INI format is specialized to provide both the ability to have a hierarchy of configuration data keys and inheritance between configuration data sections. Configuration data hierarchies are supported by separating the keys with the dot or period character (.). A section may extend or inherit from another section by following the section name with a colon character (:) and the name of the section from which data are to be inherited.

From Zend_Config_Ini page.

The Zend Framework uses it to allow you to have multiple configuration parameters, one for staging, one for development and one for production. This also allows for easy setting database settings for production, and for development and having two very different settings. Different paths set up in the ini file to where includes are located. This makes it much easier to move code from development to production knowing that immediately everything that is development will be turned off.

Sure, this would be possible with a PHP script, but it would require more parsing of the various configuration variables as well as doing if/then checks, whereas using the parse_ini_file() does all of this for you automatically.

The other answers also already pointed out that non-programmers may need to change variables and or something on the website that is set as a configuration variable (for example, site title that is used in the sites layout). INI files are easy to understand and read even for someone that has never programmed before.

Example from a website I am currently working on:

[production]
phpSettings.display_startup_errors = 0
phpSettings.display_errors = 0
includePaths.library = APPLICATION_PATH "/../library"
bootstrap.path = APPLICATION_PATH "/Bootstrap.php"
bootstrap.class = "Bootstrap"
resources.frontController.controllerDirectory = APPLICATION_PATH "/controllers"
resources.layout.layoutPath = APPLICATION_PATH "/layouts/scripts"
resources.db.adapter       = "PDO_SQLITE"
resources.db.params.dbname = APPLICATION_PATH "/../data/db/users.db"

resources.view[] =

[staging : production]

[testing : production]
phpSettings.display_startup_errors = 1
phpSettings.display_errors = 1
resources.db.params.dbname = APPLICATION_PATH "/../data/db/users-testing.db"

[development : production]
phpSettings.display_startup_errors = 1
phpSettings.display_errors = 1
resources.db.params.dbname = APPLICATION_PATH "/../data/db/users-dev.db

It makes it extremely easy to have multiple data sets for the various environments in which the code can be run.

回答2:

For those who come to this question because they want to know if there are any performance differences between using an INI file which must be parsed and a PHP file which is simply included (And can be cached by PHP): Yes, there are differences but they are so small that it doesn't really matter.

My benchmark scenario is a config.ini file with 20 key/value pairs and a config.php file with the same 20 key/value pairs written as defines. PHP version is 5.4.9 on Ubuntu Linux 13.04.

key1 = value1
...
key20 = value20

vs.

<?php
define("key1", "value1");
...
define("key2", "value20");

Two test scripts including the configs:

<?php
$CONF = parse_ini_file("config.ini");

vs.

<?php
require_once "config.php";

I tested the performance with ab -c 25 -n 10000.

Result without a PHP cache:

ini: Requests per second:    2660.89 [#/sec] (mean)
php: Requests per second:    2642.28 [#/sec] (mean)

Result with APC PHP cache:

ini: Requests per second:    3294.47 [#/sec] (mean)
php: Requests per second:    3307.89 [#/sec] (mean)

I ran the tests multiple times, naturally the numbers will vary every time but the consensus is: config.ini is a little bit faster when no PHP cache is used, config.php is a little bit faster when a PHP cache is used. But the difference is so small that the decision should not be based on performance.

回答3:

Your question raises a fair point, to be sure.

A few points in favor of .ini files:

• Use the file with another language. If you ever wanted to have a Perl, Python, Ruby, etc. script do something that is particularly easy with that language and needed to access the project settings you would be out of luck if you stored your settings in a PHP file.

• Human editing of data. Although you dismissed it in your question, intentions or not it is very likely someone might end up poking in there and it may not be a technical individual. The INI format is a lot less scary than PHP code, even if it is just a bunch of variable declarations

• Updating the settings. I think it is much easier to create a new INI file rather than writing a PHP file. This is pretty subjective, however, but it is worth mentioning.

• Relationship between setting variables. It is fairly easy/intuitive to give your settings a hierarchy with a INI file. While this would also be possible with PHP it is not as neat and can get unsightly if you are trying to do deeply nested associative arrays to store information.

In addition to those, the knock on INI of "having to protect it against web access" is not relevant in most scenarios as most PHP projects (at least the ones I'm part of) hold a fair amount of code away from the root folder, and the settings usually go there.

回答4:

Well it might be easier for a non programmer to modify config variables... If that's necessary at your workplace.

I've discovered careful placement of the <?php and ?> can stop it from being displayed, whilst the parse_ini_file() will still get the relevant data from the file.

Best way to secure it though, is to place it above the docroot, and deny access to *.ini in your server setup.