Geeklog Forums

The config.php has become quite a big file and meanwhile I think it would indeed be easier to visually see the adjustments e.g. in form of check boxes etc.

I had a look how other CMS solve this problem. Drupal has a split config. One part has to be manually written and FTPed to the webspace. It contains the MySQL password and paths etc. The other part is configured online. It contains the name of the site, the location of the logo and many other things.

I think this makes life much easier when you can adjust 'non-dangerous' things online and have a visual help. E.g. the documentation could be linked to each point and colours could be used.

With the Admin Toolbox ( cedit.php ) you can already now edit the (whole) config online: http://gplugs.pigstye.net/staticpages/index.php/20030301113613982
I already tested excluding the password part of the config.php wrote it into a password.php and included it with require_once( 'path/to/password.php' ) This works fine but it is still a text file.

What I would like is one step further also to have a stylish look and feel for the new webmaster who is spoiled by all the auto installations. And as I said an HTML layout could help with orientation.

Personally, I think most of the config properties should be in the database. Loaded by lib-common.php between lib-database and lib-security. Thus only those properties needed to get the database up and running and to get the paths setup are needed in the core config.php.

My only concern is that plugins do not use the standard $_CONF variable and thus are left in the cold if config is moved to the DB. What GL really needs is a small API like "CONF_get($key, $owner = 'core')" to replace raw array references like $_CONF[$key]. And a registrations api like CONF_registerInt($owner, $key, $default), CONF_registerString($owner, $key, $default), etc. The table layout would be something like:

conf_id NUMBER(8 ) NOT NULL AUTO_INCREMENT,
conf_key VARCHAR(48 ) NOT NULL,
conf_owner VARCHAR(24) NOT NULL,
conf_type INT(1) NOT NULL,
conf_help VARCHAR(256),
conf_default VARCHAR(256),
PRIMARY KEY (conf_id),
UNIQUE KEY (conf_owner, conf_key)

Of course a quick grep of the 1.4 source tree reveals over 8000 instances of $_CONF so this isn't something we could just hack. It would be a project for a 1.5 release. And you can't just search and replace them since you also have to delete the references to $_CONF in the global statements of most functions.

Interesting! I don`t understand the advantage of your idea as I am no programmer at all. I would have thought the config.php resides in the RAM of the server and can be called pretty quickly. If it is in the MySQL then this MySQL would be called the mentioned 8000 times.