Tuesday 30 June 2009 10:41:17 am - 9 replies
The current system checks ini files with the following extensions:
good practice is to use site.ini and site.ini.append.php.
By not checking the other 2 options, the code for loading ini files could be a bit quicker / lighter.
The question is: is anybody still using those deprecated formats? Shall we just abandon them for 4.2?
Tuesday 30 June 2009 11:50:25 am
Some extensions from projects.ez.no provide some .ini.append files (powercontent, extract, xajax, ...). I never see a *.ini.php and but some extensions from projects.ez.no seems to provide one . As others, I would vote for a script that lists and renames files. It would be interesting to throw a warning and propose to rename faulty files in setup/extensions in the admin interface too.
Tuesday 30 June 2009 12:28:38 pm
I'm in favor of removing it, BUT I do use .ini.php on one project after I learned about it by hacking on eZINI last year.
This is how it is used:
* settings is in svn
* there are three servers, and they share most of the settings, but a few are unique pr server (Session name is one, since two of the servers are behind load balancer and share host name).
So I keep common site.ini settings in settings/override/site.ini.php and server specific settings in settings/override/site.ini.append.php.<last-ip-part> and hard link site.ini.append.php to the correct file pr server.
This also means I can override db settings with unversioned site.ini.append.php locally while developing.
So if this is removed, maybe its time to blow off some dust from the old suggestion to add pr server setting?
UPDATE: When talking about an issue, its quite ok to link to it gg =): http://issues.ez.no/IssueView.php?Id=15081&activeItem=6
Modified on Tuesday 30 June 2009 12:32:34 pm by André R
Sunday 27 September 2009 11:56:20 am
Just looking at eZ Find 2.0.0 extension, which by default has two just *.ini files:
Also, there are no <b>don't edit this file</b> notices in there, so I expect that there might be users out there who will leave those files with custom settings and unchanged extensions.
Not a potential security problem?
PS. Also in favor of removing unnecessary options...
Tuesday 23 February 2010 10:29:13 am
@piotrek: thinking more about this, I agree with your comment.
Even though the base settings are called .ini, I think that it would me simpler fi we started out with basic settings that are encapsulated in php comments. This way the 'right way' to define new ini files will be more apparent to extension coders. And it becomes easier for development overall - we only have one ini format.
So I propose now to have:
and scrap the rest
You must be logged in to post messages in this topic!