Difference between revisions of "SoC config.php GUI"
(Added prototype image) |
m (Categories) |
||
| Line 34: | Line 34: | ||
On a side note, the question marks link to the documentation which already contains anchors for every config option (e.g. [http://www.geeklog.net/docs/config.html#desc_storysubmission config.html#desc_storysubmission]). | On a side note, the question marks link to the documentation which already contains anchors for every config option (e.g. [http://www.geeklog.net/docs/config.html#desc_storysubmission config.html#desc_storysubmission]). | ||
| + | |||
| + | |||
| + | [[Category:Summer of Code]] [[Category:Development]] | ||
Revision as of 11:37, 8 March 2007
Incentive
config.php is Geeklog's central configuration file with well over 150 configuration options. While some of these options only have to be set once (on the initial install of the site) others may require changes during the normal operation of the site.
Since config.php is a PHP source file, syntax errors are a common source of problems for less experienced users. Overall, however, it's simply inconvenient having to download, edit, and upload the file again just to make a simple configuration change.
In addition to the main config.php file, plugins for Geeklog will usually have their own config.php file which, while usually much smaller, suffers from the same basic problems.
Goals
The goal of this project is to provide a user interface from within Geeklog's administration pages to make configuration changes easier, less error prone, and overall more convenient.
Details
config.php uses a global array, $_CONF, to store all the configuration options (plugins use similar arrays, e.g. the Links plugin uses $_LI_CONF). $_CONF is accessed directly from a lot of places in the core code as well as 3rd party code and therefore has to stay and contain the proper values at all times. Whether this will be accomplished by the configuration GUI writing to config.php or keeping a copy of the options in the database and populating $_CONF from there will have to be discussed (writing to config.php certainly has security implications).
Changes required to update the GUI frontend for config.php when new config options are introduced should be kept at a minimum. Preferrably, the GUI could be created automatically from a description of the config options, e.g. name, type (int, string, ...), allowed values, etc.
The GUI code should easily be reusable for plugins.
Exceptions
Certain configuration options shouldn't be configurable from the GUI, e.g. the basic paths of the system, database information, and such (details to be specified). Special care has to be taken such that these can not be overriden from GUI (e.g. by sending manipulated POST requests).
A Prototype
The above screenshot is from an early prototype (back from 2003) to give an idea how this could look like. It contained hard-coded information about the config options and was therefore able to display "storysubmission" as a checkbox. For options it doesn't know anything about (e.g. "listdraftstories", which was introduced later) it simply displayed an edit field.
On a side note, the question marks link to the documentation which already contains anchors for every config option (e.g. config.html#desc_storysubmission).
