I have been messing with mediawiki 1.18 for a while now. I think what it needs is an administration page.
Why is there a reliance on manually editing LocalSettings.php and uploading it to the site? Why is there not an Admin page that edits this online?
I would love to implement this but it might just be out of my ability to do so.
It is so difficult to understand mediawiki settings and the mediawiki online-help is not very helpful.
What do you think?
Thank you.
An excellent question, Greg. Unfortunately the most common reply you will get will probably be "write one yourself."
Creating GUI's seems for whatever reason to be outside the comfort level of most programmers.
"Comment? Why would I comment my own code?"
"Help? Why would I need a help file for my own program?"
"Admin page? Why would I need an admin page to do stuff for me that I already know how to do?"
See how it goes?
Why is there a reliance on manually editing LocalSettings.php and uploading it to the site? Why is there not an Admin page that edits this online?
On Sun, Feb 5, 2012 at 7:32 AM, Steve VanSlyck s.vanslyck@spamcop.netwrote:
An excellent question, Greg. Unfortunately the most common reply you will get will probably be "write one yourself."
Creating GUI's seems for whatever reason to be outside the comfort level of most programmers.
"Comment? Why would I comment my own code?"
"Help? Why would I need a help file for my own program?"
"Admin page? Why would I need an admin page to do stuff for me that I already know how to do?"
See how it goes?
Why is there a reliance on manually editing LocalSettings.php and
uploading it to the site? Why is there not an Admin page that edits this online?
______________________________**_________________ MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.**org MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/mediawiki-lhttps://lists.wikimedia.org/mailman/listinfo/mediawiki-l
If you think that the problem is that we don't want to create a GUI for the configuration you're horribly mistaken. The problem is backwards compatibly and complex configurations like in use at the foundation. I can throw some radios and checkboxes on a special page in no time, the problem is making it work, and work well (as well as not suck like the Configure extension).
Chad (^demon) did do some work to start supporting a DB based config setup, although I don't believe he had the time to really work on that so it has stagnated (If anyone else wants to pick it up and do some work on it)
Why is there a reliance on manually editing LocalSettings.php and uploading it to the site? Why is there not an Admin page that edits this online?
"Config file vs. GUI admin page" is a religious issue for systems in general. If you're running one just one wiki, say, as a hobby, then a GUI would probably be simpler. As the sysadmin of 15+ MediaWiki sites (config file) and 10+ WordPress sites (GUI that saves to a database) at a company, however, I have found MediaWiki's config files much easier to maintain than WordPress's settings GUI & database, to keep the settings of all our sites in sync. (With a GUI you often want a database, not a config file, to support concurrent edits by multiple admins.)
Config files have these advantages:
1. Config changes can easily be tracked, rolled back, diffed, etc., using any off-the-shelf version control system. (Even if your GUI can generate a config file to be version controlled, you don't know that its final form will exactly reflect the change you made: the "save" function might reorder lines, reformat the text, add unwanted commands that set default values, etc. This screws up diffs.)
2. "Undo" is easy, no matter how long ago you made the change. When I change settings in the WordPress GUI and click "OK" or "Save", I sometimes have to work hard to roll back those changes or even remember what they were.
3. You can put anything you want into the MediaWiki config file (arbitrary PHP code) instead of whatever limited functionality that the GUI designers believed would be useful. This is invaluable. Possibly you could factor out the simpler settings into a GUI tool.
4. Config files are easily deployed to multiple targets as part of a formal release process: e.g., rsync to your 10+ wikis. With WordPress, I pull my hair out every time an admin makes a change through the GUI on one site and doesn't document it. It can be hard to identify that change so it can be documented, version-controlled, and deployed to other sites.
5. With config files, you can use your favorite editor (emacs, vi, etc.) instead of whatever the GUI designer gives you, which means I can work faster with fewer errors using familiar tools.
The main advantage of a GUI, if it's designed VERY well, is simplicity, making administration accessible to less technical people. That's not an issue for my team (we're all technical). But I can imagine that a GUI for changing basic MediaWiki settings would be useful for some admins.
DanB
On Sun, Feb 5, 2012 at 9:44 AM, Daniel Barrett danb@vistaprint.com wrote:
Why is there a reliance on manually editing LocalSettings.php and
uploading it to the site?
Why is there not an Admin page that edits this online?
"Config file vs. GUI admin page" is a religious issue for systems in general. If you're running one just one wiki, say, as a hobby, then a GUI would probably be simpler. As the sysadmin of 15+ MediaWiki sites (config file) and 10+ WordPress sites (GUI that saves to a database) at a company, however, I have found MediaWiki's config files much easier to maintain than WordPress's settings GUI & database, to keep the settings of all our sites in sync. (With a GUI you often want a database, not a config file, to support concurrent edits by multiple admins.)
Config files have these advantages:
- Config changes can easily be tracked, rolled back, diffed, etc., using
any off-the-shelf version control system. (Even if your GUI can generate a config file to be version controlled, you don't know that its final form will exactly reflect the change you made: the "save" function might reorder lines, reformat the text, add unwanted commands that set default values, etc. This screws up diffs.)
- "Undo" is easy, no matter how long ago you made the change. When I
change settings in the WordPress GUI and click "OK" or "Save", I sometimes have to work hard to roll back those changes or even remember what they were.
- You can put anything you want into the MediaWiki config file (arbitrary
PHP code) instead of whatever limited functionality that the GUI designers believed would be useful. This is invaluable. Possibly you could factor out the simpler settings into a GUI tool.
- Config files are easily deployed to multiple targets as part of a
formal release process: e.g., rsync to your 10+ wikis. With WordPress, I pull my hair out every time an admin makes a change through the GUI on one site and doesn't document it. It can be hard to identify that change so it can be documented, version-controlled, and deployed to other sites.
- With config files, you can use your favorite editor (emacs, vi, etc.)
instead of whatever the GUI designer gives you, which means I can work faster with fewer errors using familiar tools.
The main advantage of a GUI, if it's designed VERY well, is simplicity, making administration accessible to less technical people. That's not an issue for my team (we're all technical). But I can imagine that a GUI for changing basic MediaWiki settings would be useful for some admins.
DanB
Ironic, but a wiki page itself has most of those advantages.
--Fred
"FG" == Frederick Grose fgrose@gmail.com writes:
- With config files, you can use your favorite editor (emacs, vi, etc.)
instead of whatever the GUI designer gives you
Which if (single point of failure) breaks, leaves one out of business to boot.
There's no reason that GUI failure need prevent text editor access to a configuration file.
----- Original Message ----- From: jidanni@jidanni.org To: mediawiki-l@lists.wikimedia.org Date: Tue, 07 Feb 2012 16:43:53 +0800 Subject: Re: [Mediawiki-l] An Administration Page
"FG" == Frederick Grose fgrose@gmail.com writes:
- With config files, you can use your favorite editor (emacs, vi, etc.)
instead of whatever the GUI designer gives you
Which if (single point of failure) breaks, leaves one out of business to boot.
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
On 7 February 2012 14:04, Steve VanSlyck s.vanslyck@spamcop.net wrote:
There's no reason that GUI failure need prevent text editor access to a configuration file.
One might wonder if a GUI-page could overwrite one's configuration file, even accidentally. A backup would be nice in such a case. But it does create a new level of uncertainty for administrators.
I think it would be best if it was possible to hook the function for config load or overwrite whole class for config so that it's possible to create an extension which could change whole storage for configuration.
In that case we wouldn't need to change anything, the standard version would use a file, and tweaked version would have a gui.
On Tue, Feb 7, 2012 at 3:41 PM, Svip svippy@gmail.com wrote:
On 7 February 2012 14:04, Steve VanSlyck s.vanslyck@spamcop.net wrote:
There's no reason that GUI failure need prevent text editor access to a
configuration file.
One might wonder if a GUI-page could overwrite one's configuration file, even accidentally. A backup would be nice in such a case. But it does create a new level of uncertainty for administrators.
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
On Tue, Feb 7, 2012 at 9:59 AM, Petr Bena benapetr@gmail.com wrote:
I think it would be best if it was possible to hook the function for config load or overwrite whole class for config so that it's possible to create an extension which could change whole storage for configuration.
The work I plan on doing plans to support multiple backends so you can put it in CSV files if you really feel bold.
In that case we wouldn't need to change anything, the standard version would use a file, and tweaked version would have a gui.
Flip that around, we'd like to have a config gui shipped by default. As long as you use a backend that utilizes something human-readable, there's no reason you couldn't also edit the file by hand.
-Chad
Hi Chad,
I agree it would be better to have this option as a default, however it's a question if it should be hardcoded in mediawiki, or if it should be an extension, which is preinstalled in mediawiki download package and can be disabled anytime if users wouldn't like it.
I mean, if it was hardcoded, would it be possible to turn it off / use the current way of config management which is more friendly for large mediawiki installations and has better security than gui?
On Tue, Feb 7, 2012 at 4:24 PM, Chad innocentkiller@gmail.com wrote:
On Tue, Feb 7, 2012 at 9:59 AM, Petr Bena benapetr@gmail.com wrote:
I think it would be best if it was possible to hook the function for
config
load or overwrite whole class for config so that it's possible to create
an
extension which could change whole storage for configuration.
The work I plan on doing plans to support multiple backends so you can put it in CSV files if you really feel bold.
In that case we wouldn't need to change anything, the standard version would use a file, and tweaked version would have a gui.
Flip that around, we'd like to have a config gui shipped by default. As long as you use a backend that utilizes something human-readable, there's no reason you couldn't also edit the file by hand.
-Chad
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
On 7 February 2012 16:39, Petr Bena benapetr@gmail.com wrote:
I agree it would be better to have this option as a default, however it's a question if it should be hardcoded in mediawiki, or if it should be an extension, which is preinstalled in mediawiki download package and can be disabled anytime if users wouldn't like it.
Any one can write such an extension right now if they please. And has already been mentioned in this thread, people have. Although, these attempts are not very good.
I mean, if it was hardcoded, would it be possible to turn it off / use the current way of config management which is more friendly for large mediawiki installations and has better security than gui?
Of course. Ironically, however, the very setting for such would be found in the LocalSettings.php file. But I would propose that it is per default disabled, but in all new installations, the variable is set to true (unless (perhaps) disabled during the installation progress), so MediaWiki installations that have been upgraded don't find itself in a situation where another Sysop suddenly modifies the LocalSettings.php into something useless.
Which reminds me; what sort of permissions are we thinking? It should certainly be something higher than Sysop.
On 7 February 2012 15:43, Svip svippy@gmail.com wrote:
Which reminds me; what sort of permissions are we thinking? It should certainly be something higher than Sysop.
What are the permissions for the WikiAdmin account?
- d.
On 7 February 2012 16:48, David Gerard dgerard@gmail.com wrote:
On 7 February 2012 15:43, Svip svippy@gmail.com wrote:
Which reminds me; what sort of permissions are we thinking? It should certainly be something higher than Sysop.
What are the permissions for the WikiAdmin account?
There *is* a WikiAdmin account? For most installations, a Sysop is created during installation, so there is a Sysop available from the beginning. This account has no special rights other than being part of the Sysop and Bureaucrat group per default. It is quite possible (and not entirely unthinkable) that his rights might need being taken away from him. He might retire and so forth.
I presume this is the reason MediaWiki does not have a generic WikiAdmin account. My installations certainly do not, and surely hope neither does yours.
MediaWiki lacks a concept of moderators, because there has never been a need for it. The group of people you want to have access to a configuration file is usually one or two. For this Administration page to have some level of security, an entire new rights group should be created. A group above Sysops. And that's when things get tricky. Because can a Bureaucrat appoint this new group to a member? If so, that's a huge liability.
Or are bureaucrats limited to appoint position only to their level and below[1]? If so, how on a former installation being upgraded are we going to be able to appoint this new group? We cannot suggest people should manually alter some flags in the database or have the upgrader do it (that might lead to abuse or a fail prediction of a Sysop, etc.).
So if we cannot technically create a new group without serious security issues for older installations, then perhaps a password protected page; but I sincerely believe that is rather undesirable.
And we are back to why this new feature should be disabled per default.
[1] Although, I do believe that there is no 'level' system in MediaWiki, so a bureaucrat can alter anyone's group to any other group(s).
On 07/02/12 16:59, Svip wrote:
Or are bureaucrats limited to appoint position only to their level and below[1]? If so, how on a former installation being upgraded are we going to be able to appoint this new group? We cannot suggest people should manually alter some flags in the database or have the upgrader do it (that might lead to abuse or a fail prediction of a Sysop, etc.).
So if we cannot technically create a new group without serious security issues for older installations, then perhaps a password protected page; but I sincerely believe that is rather undesirable.
If old installs don't have the GUI enabled, there's no problem.
And we are back to why this new feature should be disabled per default.
[1] Although, I do believe that there is no 'level' system in MediaWiki, so a bureaucrat can alter anyone's group to any other group(s).
There are no 'levels' (this is sometimes a problem for eg. having protections greater of sysop) It is possible to restrict what can bureaucrats add by configuring the AddGroups, although in this case we would want something like "anything but this level" which isn't available yet.
On 5 February 2012 10:24, Greg greg@gajennings.net wrote:
I have been messing with mediawiki 1.18 for a while now. I think what it needs is an administration page.
Why is there a reliance on manually editing LocalSettings.php and uploading it to the site? Why is there not an Admin page that edits this online?
I would love to implement this but it might just be out of my ability to do so.
It is so difficult to understand mediawiki settings and the mediawiki online-help is not very helpful.
What do you think?
There are several things to consider for such a tool. Several have been mentioned here, but besides useability (as in, with complex configurations beyond just setting values, which are not that uncommon), the second most important issue is security.
Many have probably noticed that when you finish the installer these days, it sents you a LocalSettings.php, that you download and then upload. Why? It used to write it to the configuration-directory in the olden days; what changed? Simple; security. Allowing the webserver to write in the configuration file can be considered dangerous and potentially a big security issue.
You can then imagine the issue one might take with the idea of allowing MediaWiki to manipulate and control the configuration file. That will certainly open up the can of worms that is the configuration writing security issue.
Because even *if* you could manage to craft a GUI tool that was so sophisticated, yet so simplistic that it was usable by even the least tech-savvy out there, then it would still be the fact that at least in *any* 1.18 installation, the LocalSettings.php file is *unwriteable* by the webserver. And as I gather, there is no intend in changing that, particularly considering all the work that went into making it unwriteable when it used to be.
And obviously when it was owned by the wrong user.
Also; as an aside; it may be worth considering whether making an Administration status page might be a good idea, where Sysops can verify through the software whether the installation is sane (such as the LocalSettings.php file having the correct user, etc.).
On Sun, Feb 5, 2012 at 4:24 AM, Greg greg@gajennings.net wrote:
I have been messing with mediawiki 1.18 for a while now. I think what it needs is an administration page.
It's on the roadmap[0]. I'll be taking this issue on sometime after 1.19 and the git migration.
-Chad
mediawiki-l@lists.wikimedia.org