Re: [Phpwiki-talk] config in db

[Reini U. <ru...@x-...>]

Zot,
What you describe is the system we currently have (configurator.php) but 
nobody uses, because it's a pain to maintain, is not well supported and 
doesn't look good enough.

Joby's new Config class will help. It will also dump the configuration 
back to a file, and is easier to maintain than configurator.php.

We all understand that the current index.php with its overwhelming 
amount of not really needed options is a major turnoff for first-time 
installers.
And it's technically quite hard to use with larger wiki farms or 
multilingual wikis, but there's now code at the end to support that.

Maybe we should present some important options at the top, let the user 
run it, and let the web-based configurator do the rest.

This will need some reordering of the current chapter based index.php 
into a short index.php to get it running, and a config-dist.php (dumped 
then to config.php) which is maintainable via the configurator and 
represents all the fine tuning.

Zot O'Connor schrieb:
> On Mon, 2004-01-26 at 11:01, Steve Wainstead wrote:
>>On Jan 26, 2004, at 3:05 AM, Oliver Betz wrote:
>>
>>>Reini Urban wrote:
>>>
>>>
>>>>Why not storing the index.php configuration in the database, table
>>>>config, editable only by the admin?
>>>
>>>because it would be less transparent.
>>
>>I concur. Plain text has the main advantage that it is easily read, 
>>edited, shared, and backed up.
>>~swain
> 
> 
> Plain Text is also overwhelming as presented.  I like the idea of a
> "config" file for everything not needed in index.php.
> 
> I see a "config" file  for every day things (where's the DB, what
> sessions, server side tweaks), a config.once file for the initial boot
> process, and things which you could change on the fly, in a DB
> accessible via the web.
> 
> The last one is a tricky but important thing.
> 
> Think of the process for a newbie:
> 
>      1. You edit the minimal config file for things that need to be
>         there (DB entries, timeouts, other things, wiki name and
>         prefixes).  You probably do not need to edit config.once
>         (config.init sounds better). 
>      2. You run index.php.  It bitches about no DB loaded.  Perhaps it
>         offers to load the config file for you (which means the wikidb
>         user has table create access, a bad idea, but livable), or the
>         user has to load the DB schema by hand (current).
>      3. You get in, but things needs fixing, but *YOU GET IN*.  There is
>         no "cannot see anything so I have to edit a text file" barrier.
>      4. You tweak most things via a web interface (theme's, user names,
>         admin passwords, etc).

well written.

> The key difference of this approach over other approaches is
> *intuitive.*  It is not intuitive to do 90% of the tasks, and get 0%
> results.  This is the case of most programs.  Quicken was one of the
> first packages that let you go forward with mistakes, and then see
> results and then fix them.  This was much better than the standard "you
> must have everything right before we show the results" approach to
> software.
> 
> If you take a step back and think about, Ward's goal's for the wiki wiki
> wiki web was to reduce barriers to increase communication.  Reducing the
> steps to go live, and the possible pitfalls, and making tweaking easier
> via the web, follows Ward's goals.
> 
> And I hope by now, some of you have realized that web based
> configuration and flat file config are not incongruous.  The web
> interface must be able to write to a file on that system, and it could
> be a .ini-like file.  It could be a dbm file or sql call as well.

-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/