PHP - Application config file stored as - ini,php,sql,cached,php class,JSON,php array?

Question

I am trying to decide on the best way to store my applications configuration settings. There are so many options.

The majority of applications I have seen have used

Answer 1

The only reason I can think of to not use php vars as others are suggesting is if you need to switch between configurations in a controlled manner, so there data/behavior consistency during the switch. For example, if you're switching databases, then the system could write locked until the switch-over occurs (to prevent ghost-writes, but dirty reads are still possible).

If things like this are a concern, then you could write a special admin page in your app(pref local access only for security) that locks the system temporarily, then reads and deploys all your changes before unlocking.

If you're running a high traffic site where consistency matters, this is something you'll want to consider. If you can deploy during off hours when there is little/no traffic, then php vars or other standard text formats will be fine.

Answer 2

We use a file called Local.php which is excluded from the SCM system. It contains several constants or global variables. For example:

// Local.php
class Setting
{
   const URL = 'http://www.foo.com';
   const DB_User = 'websmith';
}

And it can be referred to anywhere simply by:

Setting::URL

If you need the settings to be writable at runtime, I suggest you use public static variables instead.

Answer 3

How about:

; <?php die('Direct access not allowed ;') ?>
; The above is for security, do not remove

[database]
name = testing
host = localhost
user = root
pass = 

[soap]
enableCache = 1
cacheTtl = 30

Save as config.php (or something like that, must have php extention), and then just load it with:

parse_ini_file('config.php', true);

And you could use

array_merge_recursive(parse_ini_file('config-default.php', true), parse_ini_file('config.php', true))

to merge a default config file with a more specific config file.

The point here is that you can use the very readable ini format, but still be able to have your config file in a public directory. When you open the file with your browser, php will parse it first and give you the result, which will just be "; Direct access not allowed ;". When you parse the file directly as an ini file, the php die statement will be commented out according to the ini syntax (;) so it will not have any effect then.

Answer 4

Try to use php-arrays config files using technique described here: http://www.dasprids.de/blog/2009/05/08/writing-powerful-and-easy-config-files-with-php-arrays

This method allows you to write app configuration in this way: app.config.php

<?php

return array(
  'appname' => 'My Application Name',
  'database' => array(
    'type' => 'mysql',
    'host' => 'localhost',
    'user' => 'root',
    'pass' => 'none',
    'db' => 'mydb',
  ),
);

This method is secure, cache-able by opcode cachers (APC, XCACHE).

Answer 5

I find Zend_Config to be a good solution. You can load the configuration from a simple array, from an INI style file, or from an XML document. Whichever you choose, the configuration object is the same, so you can switch storage formats freely. Zend_Config objects can also be merged, depending on your application this may be useful (a server config, then a per site/installation config).

As with most (or all) things in the Zend Framework, you can easily use Zend_Config by itself.

Considering efficiency, I'd say the fastest method would be to use an array, since that requires less (in this case no) string parsing. However, a INI/XML format may be easier for some to maintain. Of course some caching would give you the best of both worlds.

Also, using INI files with Zend_Config allow you to define sections of configurations that inherit from each other. The most common use is a 'development' section that inherits from the 'production' section, then redefines the DB/debugging settings.

As for security, keeping the config file out of the web root is the first step. Making it read only and limiting access could make it more secure; however, depending on your hosting/server configuration you may be limited in what can be done there.

Answer 6

Just an example of how to implement a central XML/Xpath configuration.

class Config {
    private static $_singleton;
    private $xml;
    static function getInstance() {
        if(is_null (self::$_singleton) ) {
                self::$_singleton = new self;
        }
        return self::$_singleton;
    } 
    function open($xml_file) {
        $this->xml = simplexml_load_file($xml_file);
        return $this;
    }
    public function getConfig($path=null) {
        if (!is_object($this->xml)) {
            return false;
        }
        if (!$path) {
            return $this->xml;
        }
        $xml = $this->xml->xpath($path);
        if (is_array($xml)) {
            if (count($xml) == 1) {
                return (string)$xml[0];
            }
            if (count($xml) == 0) {
                return false;
            }
        }
        return $xml;
    }
}

Example call

Config::getInstance()
    ->open('settings.xml')
    ->getConfig('/settings/module/section/item');