Comments on: Don’t use YAML for PHP, use parse_ini_file

By: Even

Even — Sun, 27 Sep 2009 12:47:33 +0000

Yes, JSON is a fair choice as stated Darkhogg. The best part about JSON is that YAML is an extension of JSON so everything written in JSON is a correct file for a YAML parser. It might be a very good point for a lot of people. But I personally love some parts of the languages extension brought by the YAML. The good way would be to have YAML support by default in PHP…

By: Darkhogg

Darkhogg — Fri, 31 Jul 2009 10:26:01 +0000

Another option for tree-structured data is JSON. PHP comes with json libraries by default, and is a pretty simple syntax you can write directly and can be shared through every language.
Since json_decode() is a built-in function, it shouldn’t be slow.

other option is using some sort of tree.structuring INI, such as Parent.child, and then in PHPH parse out the dots to make an array like $thing[’Parent’][’child’] … that can be slow too, but maybe quickier than YAML

By: counterpoint

counterpoint — Wed, 08 Apr 2009 10:58:41 +0000

For a long time the use of .ini files in PHP seemed to me a non-starter on the grounds that a syntax error in the .ini file would cause script processing to terminate. Not the parse_ini_file function, but the entire PHP script. It’s in the nature of things that people will sometimes mess up configuration files. So how would you cope with this - parse the ini file using string processing before submitting it to parse_ini_file?!

More recently the function has returned an empty array or latterly false if there is a syntax error. But even that means that no diagnostic can be given if the .ini file is in error. This seems unacceptable in any system that aims to be user friendly, even when the user messes up.

YAML, XML, RelaxNG have the advantage of being a consistent and mutually supportive set of standards that support powerful configuration storage options.

By: Eric J

Eric J — Mon, 26 Jan 2009 01:50:46 +0000

Shouldn’t this read, "Don’t use YAML for configuration files in PHP"? I’ve found YAML and SPYC to be very handy for non-configuration purposes.

By: ananda

ananda — Tue, 09 Dec 2008 02:52:36 +0000

What about MVC ?

what when the data comes from a database instead of a file ????

By: Rob Desbois

Rob Desbois — Mon, 01 Dec 2008 17:06:47 +0000

As stated by ’she’ the ini file format doesn’t support anything more complicated than (name => value) pairs.

My application requires some data which is in a structured tree format - impossible to represent in an ini file. With YAML it’s easy.
Granted there are other formats which can support it - XML being the obvious one that springs to my mind, but I dislike the overheads of the structure and the unfriendliness to someone not well-versed in it. YAML is easy to read and easy to write whether you are man or machine, and whether you are a developer or not.

By: NOTini

NOTini — Thu, 25 Sep 2008 02:48:07 +0000

sometime I wanna define a dsl style config file. the ini file looks like an ugly guy.

it’s depends on the requirement. in my project, there are tons of config files with dsl style

so I have no choice.

By: Nick J

Nick J — Thu, 22 May 2008 07:12:43 +0000

One problem with parse_ini_file is backwards compatibility, because until at least March 2007 you could not escape quotes in INI files.

E.g. if you wanted to use an INI file to do this: $array[’x'] = ‘The message said "Hello World!"…’;
… then until just over a year ago, you could not do that due to a bug - i.e. an INI file like this:
————
x = "The message said \"Hello World!\"…"
————
… would not work with parse_ini_file. Not being able to have quotes in strings is a pretty fundamental limitation, so for apps that have to support PHP5.x, that rules out using parse_ini_file.

By: she

she — Thu, 14 Feb 2008 20:45:21 +0000

Is your comment correct?

Yaml can store hashes and arrays, I dont think .ini can do.

By: Clint

Clint — Tue, 23 Oct 2007 14:56:51 +0000

yaml is basically impossible to parse in bash. Its not easy in perl (but of course, doable). ini files, however, are dead simple to parse in bash and perl. When you have a heterogeneous environment, having one spot for local config information is a huge advantage.