robchur wrote:

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?

webmaster wrote:

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...

robchur wrote:

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.

webmaster wrote:

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.

webmaster wrote:

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...

robchur wrote:

I'd say permitting uploads is a "critical" item, myself.

rowan.collins wrote:

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?

robchur wrote:

*** Bug 258 has been marked as a duplicate of this bug. ***

robchur wrote:

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."

webmaster wrote:

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?

rowan.collins wrote:

(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.

webmaster wrote:

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?

robchur wrote:

*** 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.