3

I'm working on a huge CMS system, and I asked myself what configuration format I should use.

There are two common formats for configuration files. The first one is an INI file, containg all the configuration properties. Then you can simply parse this INI file using build in PHP functions. A second option is to use a PHP file containing a regular PHP array with these configuration properties.

Now, it's easier to edit an INI file, but a PHP file give's you more options, for example it allows you to add a function which retrieves one of the configuration options while reading the configuration file.

Note: The PHP configuration file would only contain an array of configuration, no initialization functions or anything. (This is possible of course, but it's not implemented by default)

Now, what is recommend for me to use as configuration file? What is the most common format for a configuration file? Should I go for simplicity with the INI files, or with a more dynamic one using PHP.

One thing to note, this is not for personal usage. I'm planning to release the CMS system soon, and a lot of websites are scheduled already to change to my CMS system.

  • Which CMS is this? – Petah Feb 11 '15 at 9:22
17

INI files have the disadvantage that they can't elegantly represent complex data structures like arrays. Therefore they are only useful for very simple configuration. Using a PHP file for configuration can be viewed as a security problem: Any code might be entered there. Worse, a simple syntax error like forgetting a closing quote could render the whole configuration unusable.

There are already common human-readable data formats. XML is extremely powerful, but overly verbose, and not every data maps cleanly to XML. JSON is another excellent format, but has a very strict syntax.

I would urge you to consider YAML. It is extremely easy to read, and includes JSON as a subset of its syntax.

this is a key: some value here
another key:
  - this is the first item in an array
  - another one
  - { inline: dictionary, has: values }
  - [ inline array, has, more, values]
  - "Quote this, if you like"

There are many more advanced features beyond simple dictionaries and lists, making this a very flexible format.

  • INI files does support arrays as far as I know, using key[]=val1 + key[]=val2. And I understand your point about PHP files. XML and JSON is not really useful for me, because they aren't that easy to read, and people who never worked with them before usually don't understand their structure. I used YAML a lot already, with configuration files over 3000 lines and very complect structures, I like it a lot but I don't think it's perfect for my CMS system. People usually have problems with the TAB's and other little typo's. Secondly, the libraries I've seen for PHP aren't that great, ... [1/2] – Tim Visee Oct 24 '13 at 14:09
  • [2/2] ... and I don't want to create a full library meself, because YAML isn't that easy to parse. I think I'll go with INI, it's simple. The configuration file only needs sections, keys and their values, so I think INI files are perfect. Thanks for your answer though, very informative! – Tim Visee Oct 24 '13 at 14:10
  • @TimVisee PHP parsers for YAML already exist, so you wouldn't really have to write anything on your own. I didn't know about the INI-array syntax, that might be implementation-specific behaviour. But if INI fulfills all your requirements, using this is the simplest way to go (the format is rather robust against accidental typos). Have fun building your CMS! PS: thanks for using a widespread format. Bad things happen when you create your own config format – amon Oct 24 '13 at 14:16
  • Thank you for your answer and opinion again. Indeed that's what I thought about the Config files, uncommon formats are annoying to work with. And indeed the features of INI is all I need. About the YAML, I didn't know that, I'll definitly take a look in to it later on, because I really like the format and features of these files. Oh and about fun, I've already had lots of fun developing it, but thanks! – Tim Visee Oct 24 '13 at 14:24
5

One other big reason to go with PHP -- security. If you expose that .ini file to the webroot, most typical web server configurations will serve that file as a plain text file exposing whatever configuration secrets your app has. A php file containing purely code will just return a blank page, if you don't bother to take any security steps which are also an option because you are now in a programming language that gives you options.

  • I am aware of this. Of course security is important. The thing is that my CMS requires .htaccess support on the server. So I put a .htaccess file in the config directory with Deny From All, that works right? I can always change to PHP again, simply by modifying the ConfigHandler class I wrote. Thanks anyway for the answer. – Tim Visee Oct 24 '13 at 22:57
  • 4
    Sure, you can rely upon .htaccess to secure files. You just have to rely upon people properly deploying said .htaccess files all the time. I don't trust people. – Wyatt Barnett Oct 24 '13 at 23:39
3

I think you need to consider the size and complexity of the configuration needed,

Do you need to read it often? always?
Do you need to be able to override the data on certain circumstances?

In most cases I would go for a php file, specially if you can put that file outside of the web server root and as a read-only file.

YAML is nice, but I guess can be expensive to process the config file on every request, you would need some sort of cache, and that of course would add complexity for something that could be really simple.

  • Yes, I choose for INI. It's commonly used. The files aren't that complex so there's no need for PHP files. Indeed YAML files are expensive to process, you can cache the files of course, but it's still a disadvatage. Also, users usually have problems with the format of these files, TABS, typos. INI files are easy to use. Thanks for your answer anyway. – Tim Visee Oct 24 '13 at 14:21
2

I would go with a .php file. While its very minimal, an ini file is still adding overhead to each page load as it gets opened and processed every time a value is read. Even if you load the entire file into memory, you still are doing extra work looking thigns up. You'd have the same issue with .xml or other format as well. A PHP file would be loaded once, and then as a bonus, cached by any PHP caching system you might have.

And really, is there much difference between this:

somesetting = 1

and this?

$somesetting = 1;

Both are just as easy to manage.

  • 1
    The resource usage of loading a file? Jeez, we're talking about PHP here, not only does it run in an environment where total response latency is going to measured in double digit milliseconds, it has pretty slow function calls, so however you do it the overhead of loading a single file is completely negligible. Caring about nanoseconds is counter productive in that environment. – Phoshi Oct 24 '13 at 15:38
  • Well, in the first place. The configuration file is read as an array on initialization. Secondly, this array is cached. There's no way to do this quicker. Also, it's not as simple as $key = 'val';, 2d arrays are used, which make it way harder for people to understand. – Tim Visee Oct 24 '13 at 15:43
  • 1
    He said it was a 'huge' CMS, so scaling is an issue. And if PHP is that slow, why laden the CMS down even more, even if by a small amount, when there's no real benefit to the .ini over the .php file in the first place? Especially when the .php file (ie, code) can be cached in compiled form. – GrandmasterB Oct 24 '13 at 15:47
  • It's about small files, it's only a few nanoseconds difference, unoticable. I'm also caching the parsed INI file in the file system which makes it even quicker. All the other properties are stored in a database table, to make it more dynamic. The mysql credentials for example are stored in this ini config file. So this config file is very small indeed. More people know about INI files as far as I know, and people will have less parsing isues, that's why I currently go with INI files. – Tim Visee Oct 25 '13 at 0:19
  • @GrandmasterB: Configuration is one of those things where the "flexibility" of a full turing complete programming language is very very very rarely advantageous. If your configuration requires that much complexity, it isn't a configuration file, it's just another chunk of code. Consider why most large projects/frameworks eschew PHP's freeform templating, because when your templating engine is turing complete you encourage people to mix business logic in with the display code and it quickly becomes unmaintainable, wheras a more constrained environment can give a better end result. – Phoshi Oct 25 '13 at 8:31
0

You said that a lot of websites are already scheduled to change to your CMS system, so it sounds like a question for them. Will these be managed by people so programming illiterate that they would be more comfortable editing an INI file that a PHP file with simple options? Would the loss in speed from parsing the INI file be an issue for them? Would they prefer the added flexibility a PHP config file would allow? Should the security concerns of using an INI file matter to them? Or perhaps you should allow both. Perhaps some people will appreciate the ease of editing an INI file and others the advantage of a PHP file. It seems the advantages of only having a PHP config file usually outweigh that of an INI file and that of having both. Therefore, perhaps it would normally only search for a PHP file, but in the case that it is started with special options, the system could be instructed to search for an INI file or even both. If necessary, it could be instructed which config file would have the higher priority should some of the same configuration options be in both.

0

Try to answer this question individually for each configuration file. A dependency injection container tree is actually also a kind of configuration, but who could change the file? It might only be another developer.

Writing a CMS means there are configuration files like database connection setups and so on, which might be edited by any luser, but they are more computer literate people. Do you think they can handle any "Unexpected T_STRING" messages? Maybe, maybe not. I recommend YAML as configuration format for non-developers in that case. Easy to read and when I create PHP projects with symfony, I can use the configuration component (http://symfony.com/doc/current/components/config/index.html), which produces error messages which everyone understands. You define your parse and validate tree in PHP and if the yaml file cannot be parsed you have your message.

If your configuration is for real luser it might be better to use INI.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.