Re: [Phpwiki-talk] Automatic config rewriter php -> ini

[Joby W. <joby@u.washington.edu>]

Actually I was talking about a variant of #2.  Instead of an 
auto-creation of config.php (based of timestamp, etc), when using the 
CLI tool you can create a config.php from your config.ini.

#1 isn't a bad idea either, I'll put it on my todo list (though it won't 
make my initial commit).

Joby Walker
C&C Computer Operations Software Support Group


Reini Urban wrote:
> Dan Frankowski schrieb:
> 
>> One disadvantage: you'll always support two ways (ini and php). This 
>> requires more code maintenance. I claim you'd be happier if you could 
>> somehow easily migrate people, so in the end you only support one way. 
>> For example, offer a tool that takes an index.php and makes an INI 
>> file out of it. Then this tool can be deprecated and go away after a 
>> few releases.
>>
>> In general, supporting fewer ways to do the same thing in the long run 
>> is good.
> 
> 
> No, we are talking about two things:
> 
> 1. convert an existing old index.php to config/config.ini for
>    easier upgrades from < 1.3.10 to > 1.3.10
>    joby said he had something like this in the works.
> 
> 2. dump the content of an new existing config/config.ini to a
>    config/config.php (after timestamp comparison), for faster
>    load time. This is Matthew's idea. mediawiki's installer does
>    something like this also. The problem is the needed file
>    permission, similar to upload. Maybe we should ship an empty
>    but 446 config/config.php. (For freebsd it's easier, they
>    know the apache user in advance)
> 
>> Joby Walker wrote:
>>
>>> Matthew Palmer wrote:
>>>
>>>> Has anyone made any progress in this area?  The major hold-up for me
>>>> updating Debian to 1.3.1[01] is that it'll force every PHPWiki user in
>>>> Debian to rewrite their config files, which is unlikely to make them 
>>>> jump
>>>> for joy.
>>>
>>>
>>>
>>>
>>> I'm a good way toward being done.  Been busy with work, getting a new 
>>> laptop, and rebuilding my windows server at home.  Once I have the 
>>> CLI client working and tested I'll commit it.
>>>
>>>>
>>>> I did have one (potential) brain-wave, which would also, as a 
>>>> side-effect,
>>>> solve the major cause of complaint against the ini-file system.  Put
>>>> together code which parses the INI file and writes a config.php full of
>>>> define()s and whatever else takes your fancy, and source *that* 
>>>> instead of
>>>> doing an INI parse every invocation.  Then, just have a bit of code 
>>>> that
>>>> compares the mtime of config.ini with that of config.php, and rewrite
>>>> config.php if it's older than config.ini.  The first user to hit the 
>>>> new
>>>> config file gets a 1-2 second slowdown, maybe, but that can be 
>>>> server lag,
>>>> and everyone else gets smokingly fast response times.
>>>>
>>>
>>> Yeah thought of that too.  It'll be an option for the CLI client to 
>>> build a config.php.  Then if config.php is present it'll use it 
>>> instead of config.ini.