Last modified: 2010-05-15 15:37:22 UTC
MediaWiki software's post-installation administrative capabilities seems somewhat lacking. A small, simple 'super-admin console' with functionality such as password resets might be a great convenience. Not all wikis have the email function enabled (or working) and hence self-initiated password resets might not be possible. The 'admin console', limited access to 'super- admins' or the like, might be a great place to put many such configuration settings. Smaller wiki sites are able to 'micro-manage' their site and community, unlike Wikipedia that must be mostly automated for convenience sake.
I think this would be a good idea, actually; implement a new special page; Special:Passwordreset. What other functions did you have in mind, however?
It is a short list of 'new' ideas so far, but I am sure with time I (we) could come up with more thoughts. * Image Renaming * User Renaming * Password resets Also, I thought of bringing existing features currently in LocalSettings.php to an interface format. (Again I want to re-iterate this "Admin-Console" should not be for "Admins" only "SUPER-Admins") I know there is no such thing as "Super-Admins", but again looking at this from a non-wikipedia, small-time-joe perspective this will make site administration so much easier. Examples of configurations currently in LocalSettings.php I propose we add to the Admin-Console are: * Enable/Disable uploads * Enable/Disable email (& SMTP configuration) * Enable/Disable Raw HTML * Enable/Disable User Java/CSS * Invalidate cache ($wgCacheEpoch) * The entire group permissions array * Minimum password length * etc, etc. This would of course need to be handled with the utmost concern for security and user-authentication as such an Admin-Console in the wrong hands could create havok for a wiki...
We'd be looking at moving a lot of configuration information to the database in order to do that, but I do like the idea...sort of. I think I would prefer special pages to do some of this, e.g. Special:Resetpassword or Special:Renameuser - the latter already available through an extension. Does MediaWiki permit one to specify a minimum password length? I wasn't aware of such a feature.
Yes. I think I first noticed it in version 1.5.0. It is called $wgMinimalPasswordLength, on line 1497 of the DefaultSettings.php. There are a few new fun features... You should browse the DefaultSettings file again... (Because the docs sure aren't up to date! (See also, Bug 1)) :) Anyways... I am not sure why everyone on this project is so dead-set about making the install/configuration more complex than it has to be. I mentioned fixing up the install interface and was met with: "That is what the LocalSettings.php file is for!" I am somewhat familiar with php and html and such, but not everyone is. GUI's were invented 15 years ago... Shouldn't we take advantage of this wonderful 'new' techology? You say it would be a lot of work... I very much agree. Still, wouldn't it be worth it for those folks who might use MediaWiki if it were a bit easier to setup/maintain?
In general I'd be leery of putting settings in the database; an SQL-level injection able to change certain settings could lead to code execution or other nasties (eg, replacing the $wgTexvc command with a rootkit downloader). Note also that MediaWiki's target audience is large, centrally managed sites that need to maintain several hundred wikis off of a single shared, but flexible, configuration.
Brion, Point well taken. I did realize it would open up several new 'cans of worms' security-wise, but maybe only a few non-critical items such as Enable/Disable uploads, Enable/Disable email (& SMTP configuration), Invalidate cache ($wgCacheEpoch), etc wouldn't cause too much of a security nightmare. Also, I didn't realize most end-users were large sites (WikiCities, etc), I figured, going forward, more and more 'small-fries' would take advantage of this AMAZING software...
I'd say permitting uploads is a "critical" item, myself.
It occurred to me ("a blinding flash of the obvious", as my dad would say) in pondering bug 4262 that there is a way to combine the flexibility and efficiency of a static LocalSettings.php file with the ease-of-use and automation of an admin interface: create an interface which *generates* the PHP file. This way, no settings need to be in the database, and the admin interface needn't even have direct write access to the settings (though the option to enable that could be included, with big red security warnings). Of course, all sorts of systems already do this - think of the unified configuration tools in Linux distributions ("dpkg-reconfigure mediawiki" :p), for instance; in fact, the installer already lets you set some things on an HTML form which then end up in LocalSettings.php. Since shell access is far from guaranteed, this would probably be a web-based interface, but the central point is the same: a form would be presented with a number of commonly-used configuration options; toggling these would perform various sanity checks, like checking for conflicting settings, and set one or more options, possibly based on yet other options, or even database content. By running as part of MediaWiki itself, it could know the current state of settings simply by executing the initialisation scripts itself. And when it changed options, it could set those variables in its own environment as well as in its prospective output [so they'd always be consistent, even if you changed several in a session before clicking "save"]. To actually output the string, it would presumably grep for the current string for that setting, delete or comment it, and add an adjacent line with the new setting; new settings could either go at the end of the file or in specially marked sections (e.g. "/* ==Image settings== */") The result would be a modified LocalSettings.php, either output to the user, or saved to the installation directory (as, say, "LocalSettings.auto"). Somebody with real server access would then copy it over the existing file, and hey presto! And, like I say, if someone really trusted the security of the config interface, they could grant it [manually, on the server] the ability to overwrite the file directly (after making a backup). True, it would still require manual intervention on the server, but it would make the configuration itself much more self-documented... So, other than "why don't you code it then, clever-clogs?", what are people's thoughts?
*** Bug 258 has been marked as a duplicate of this bug. ***
Comment merged over from bug 258: "If I choose the invitation-only, closed shop setting in LocalSettings.php, I have to manually edit $wgWhitelistRead in the file to add new pages for public viewing. I don't always have shell access to do it and that's a bother anyway. It would be nice if, as a sysop, I could add or remove a page from the whitelist while viewing it on my wiki, just like I can protect it."
Bug 4886 talks about intelligent (automated) server-side intra-wiki link rendering... The user-defined list of 'linkable' words could be easily maintained from this proposed admin-console. Also, I like the talk of maintaining such items as the filetype whitelist and user/group permissions from the console. Any new thoughts on this?
(In reply to comment #11) > Bug 4886 talks about intelligent (automated) server-side intra-wiki link > rendering... The user-defined list of 'linkable' words could be easily maintained > from this proposed admin-console. Well, there's no particular need for that to be done through a special "admin console" - whoever implements the "wikifier" can store the word list in the database, and have a normal Special: page for editting it (with appropriate permissions required). If it *did* end up in LocalSettings.php, though, any admin interface would easily be able to accomodate it (or it would the way I was thinking of it). Unfortunately, I just got a full-time job, so my plans for world domination / MediaWiki coding may be more on hold than usual.
I thought of a few more settings that could go in the 'admin console'. How about defaults for things like: How many images to show in categories (currently at 200, could change to 20/50/100/200) How many changes to show in recent changes (for not logged in users) Maximum size for image uploads (warning size as well) Also, an easier place for modifying MediaWiki:Sidebar and MediaWiki:Sitenotice... (not that I didn't LOVE the new sidebar interface!) I know I am stretching to bring everything into an interface, but remember, folks who Administrate websites are often not php/mysql programmers. If MediaWiki is intended for use by large organizations, shouldn't there be a great deal of separation from code/files to site administration? Not too many site admins I know (myself included) are willing to delve into lines of code, (nor adept enough) just to 'invalidate cache ($wgCacheEpoch)'. Brion / Rob Church: Can I get some additional thoughts by you guys on this?
*** Bug 5654 has been marked as a duplicate of this bug. ***
Between various extensions (PasswordReset, RenameUser and Configure), I think all the things this bug is asking for have been done. Closing as FIXED.
