I mean storing most local settings into database, and administrators can modify it online via a dedicated configuration php page. Thus less efforts are needed for administration and updating to new version of mediaWiki. Most page interface messages can be stored in DB, why not to store those essential configuration information? The best case would be to use newversion immediately after unpacking mediawiki-x-x.tar to the original www root. I am tired of editing LocalSettings.php for already. :-) It is like programming, not administration.
Kiss All wrote:
I mean storing most local settings into database, and administrators can modify it online via a dedicated configuration php page. Thus less efforts are needed for administration and updating to new version of mediaWiki. Most page interface messages can be stored in DB, why not to store those essential configuration information? The best case would be to use newversion immediately after unpacking mediawiki-x-x.tar to the original www root. I am tired of editing LocalSettings.php for already. :-) It is like programming, not administration.
Hello,
I am already thinking about it, unfortunatly I will not be able to code anything about it before november.
Maybe some other developper will do it :p
You'll still need to have a LocalSettings.php for at least a few settings, such as those for $wgDBserver, $wgDBname, $wgDBuser, and $wgDBpass, plus whatever settings are needed by the scripts to read data from the db.
Otherwise you'll have a chicken-and-egg problem of not knowing how to actually read your preferences out of the database.
-Nick
Ashar Voultoiz wrote:
Kiss All wrote:
I mean storing most local settings into database, and administrators can modify it online via a dedicated configuration php page. Thus less efforts are needed for administration and updating to new version of mediaWiki. Most page interface messages can be stored in DB, why not to store those essential configuration information? The best case would be to use newversion immediately after unpacking mediawiki-x-x.tar to the original www root. I am tired of editing LocalSettings.php for already. :-) It is like programming, not administration.
Hello,
I am already thinking about it, unfortunatly I will not be able to code anything about it before november.
Maybe some other developper will do it :p
On Mon, Sep 13, 2004 at 09:54:41PM +0200, Ashar Voultoiz wrote:
Kiss All wrote:
I mean storing most local settings into database, and administrators can modify it online via a dedicated configuration php page. Thus less efforts are needed for administration and updating to new version of mediaWiki. Most page interface messages can be stored in DB, why not to store those essential configuration information? The best case would be to use newversion immediately after unpacking mediawiki-x-x.tar to the original www root. I am tired of editing LocalSettings.php for already. :-) It is like programming, not administration.
Hello,
I am already thinking about it, unfortunatly I will not be able to code anything about it before november.
Maybe some other developper will do it :p
I've a UI for editing the site preferences, I'm just not yet sure how to store the settings. one big blob, with old versions kept around, or as a table with name=>value pairs? Probably have to replace all globals by a $globalConfig[] array to make storing/retrieving faster/easier.
Any ideas?
JeLuF
JeLuF wrote:
I've a UI for editing the site preferences, I'm just not yet sure how to store the settings. one big blob, with old versions kept around, or as a table with name=>value pairs? Probably have to replace all globals by a $globalConfig[] array to make storing/retrieving faster/easier.
Any ideas?
JeLuF
Lo JeLuF,
Probably better to get one row per setting, that will allow us to sort settings per categories and define the type of data.
Ex: category | setting | value | type --------------------------------------------- General | ScriptPath | | string General | UploadDir | /mnt/upload | string Tidy | UseTidy | 0 | boolean ---------------------------------------------
Then we can get different administrations pages.
For older versions, we probably just want to diff changes and saves them directly in the new log system.
I will be out till october ... :(
cheers,
On Tue, Sep 14, 2004 at 07:57:06AM +0200, Ashar Voultoiz wrote:
Lo JeLuF,
Salut,
Probably better to get one row per setting, that will allow us to sort settings per categories and define the type of data.
Ex: category | setting | value | type
General | ScriptPath | | string General | UploadDir | /mnt/upload | string Tidy | UseTidy | 0 | boolean
Then we can get different administrations pages.
I already have different pages, much like the User Preferences page. Also grouping and sorting them in the single pages, I think hardcoding this in PHP is fine, no real need to get the layout of the forms from the DB.
For older versions, we probably just want to diff changes and saves them directly in the new log system.
Good idea. Visible to sysops and developers only. Special:Sitesettings for developers only.
Draft is at http://mediawiki.mormo.org/index.php/Special:Sitesettings
Not all messages are defined yet. Prototype. Save not implemented.
Regards,
JeLuF
I am very happy to see the progress you guys have made so far! Thank you very much for your good work!
On Tue, 14 Sep 2004 19:46:36 +0200, Jens Frank jeluf@gmx.de wrote:
On Tue, Sep 14, 2004 at 07:57:06AM +0200, Ashar Voultoiz wrote:
Lo JeLuF,
Salut,
Probably better to get one row per setting, that will allow us to sort settings per categories and define the type of data.
Ex: category | setting | value | type
General | ScriptPath | | string General | UploadDir | /mnt/upload | string Tidy | UseTidy | 0 | boolean
Then we can get different administrations pages.
I already have different pages, much like the User Preferences page. Also grouping and sorting them in the single pages, I think hardcoding this in PHP is fine, no real need to get the layout of the forms from the DB.
For older versions, we probably just want to diff changes and saves them directly in the new log system.
Good idea. Visible to sysops and developers only. Special:Sitesettings for developers only.
Draft is at http://mediawiki.mormo.org/index.php/Special:Sitesettings
Not all messages are defined yet. Prototype. Save not implemented.
Regards,
JeLuF
Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Jens-
Draft is at http://mediawiki.mormo.org/index.php/Special:Sitesettings
Do you intend to port the existing explanations of what each option does into this interface? If so, it would probably make sense to have separate messages for these so we can experiment with different layouts for the help.
Regards,
Erik
On Wed, Sep 15, 2004 at 03:08:00AM +0200, Erik Moeller wrote:
Jens-
Draft is at http://mediawiki.mormo.org/index.php/Special:Sitesettings
Do you intend to port the existing explanations of what each option does into this interface? If so, it would probably make sense to have separate messages for these so we can experiment with different layouts for the help.
The existing explanations, if they are good, are to verbose for the admin interface. I thought about having a help button per page or even per option.
Per page would allow having an introduction providing some overall picture, e.g. for memcached, there has to be a discussion in the help explaining what memcached is for and who should use it and where to get it. This I wouldn't want to see as part of the site settings page itself, but in a help page.
Regards,
JeLuF
Jens Frank wrote:
On Tue, Sep 14, 2004 at 07:57:06AM +0200, Ashar Voultoiz wrote:
Lo JeLuF,
Salut,
Probably better to get one row per setting, that will allow us to sort settings per categories and define the type of data.
Ex: category | setting | value | type
General | ScriptPath | | string General | UploadDir | /mnt/upload | string Tidy | UseTidy | 0 | boolean
Then we can get different administrations pages.
I already have different pages, much like the User Preferences page. Also grouping and sorting them in the single pages, I think hardcoding this in PHP is fine, no real need to get the layout of the forms from the DB.
For older versions, we probably just want to diff changes and saves them directly in the new log system.
Good idea. Visible to sysops and developers only. Special:Sitesettings for developers only.
Draft is at http://mediawiki.mormo.org/index.php/Special:Sitesettings
Not all messages are defined yet. Prototype. Save not implemented.
Regards,
JeLuF
Hello,
Looks good JeLuF. My idea of a "category" field is to allow developpers to add new options easily and get the interface to update itself automaticly. This way we will just care about the code and can forget the interface.
With a new user right system, we can even have different administrators, with some being able to access the "general" changes but not the "tidy" or "memcached" settings.
cheers,
wikitech-l@lists.wikimedia.org