An Administration Page

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

An Administration Page

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


_______________________________________________
MediaWiki-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Reply | Threaded
Open this post in threaded view
|

Re: An Administration Page

Steve VanSlyck
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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Reply | Threaded
Open this post in threaded view
|

Re: An Administration Page

Daniel Barrett-3
In reply to this post by Greg
>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

_______________________________________________
MediaWiki-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Reply | Threaded
Open this post in threaded view
|

Re: An Administration Page

Frederick Grose
On Sun, Feb 5, 2012 at 9:44 AM, Daniel Barrett <[hidden email]> 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:
>
> 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
>

Ironic, but a wiki page itself has most of those advantages.

       --Fred
_______________________________________________
MediaWiki-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Reply | Threaded
Open this post in threaded view
|

Re: An Administration Page

John Du Hart
In reply to this post by Steve VanSlyck
On Sun, Feb 5, 2012 at 7:32 AM, Steve VanSlyck <[hidden email]>wrote:

> 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
> [hidden email].**org <[hidden email]>
> https://lists.wikimedia.org/**mailman/listinfo/mediawiki-l<https://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).

--
John
_______________________________________________
MediaWiki-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Reply | Threaded
Open this post in threaded view
|

Re: An Administration Page

K. Peachey-2
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)

_______________________________________________
MediaWiki-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Reply | Threaded
Open this post in threaded view
|

Re: An Administration Page

Svip
In reply to this post by Greg
On 5 February 2012 10:24, Greg <[hidden email]> 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.).

_______________________________________________
MediaWiki-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Reply | Threaded
Open this post in threaded view
|

Re: An Administration Page

jidanni
In reply to this post by Frederick Grose
>>>>> "FG" == Frederick Grose <[hidden email]> writes:
>> 5. 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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Reply | Threaded
Open this post in threaded view
|

Re: An Administration Page

Steve VanSlyck
There's no reason that GUI failure need prevent text editor access to a configuration file.

----- Original Message -----
From: [hidden email]
To: [hidden email]
Date: Tue, 07 Feb 2012 16:43:53 +0800
Subject: Re: [Mediawiki-l] An Administration Page

> >>>>> "FG" == Frederick Grose <[hidden email]> writes:
> >> 5. 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
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
>

_______________________________________________
MediaWiki-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Reply | Threaded
Open this post in threaded view
|

Re: An Administration Page

Chad
In reply to this post by Greg
On Sun, Feb 5, 2012 at 4:24 AM, Greg <[hidden email]> 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

[0] http://www.mediawiki.org/wiki/Roadmap#May_2012

_______________________________________________
MediaWiki-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Reply | Threaded
Open this post in threaded view
|

Re: An Administration Page

Svip
In reply to this post by Steve VanSlyck
On 7 February 2012 14:04, Steve VanSlyck <[hidden email]> 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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Reply | Threaded
Open this post in threaded view
|

Re: An Administration Page

Petr Bena
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 <[hidden email]> wrote:

> On 7 February 2012 14:04, Steve VanSlyck <[hidden email]> 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
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
>
_______________________________________________
MediaWiki-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Reply | Threaded
Open this post in threaded view
|

Re: An Administration Page

Chad
On Tue, Feb 7, 2012 at 9:59 AM, Petr Bena <[hidden email]> 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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Reply | Threaded
Open this post in threaded view
|

Re: An Administration Page

Petr Bena
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 <[hidden email]> wrote:

> On Tue, Feb 7, 2012 at 9:59 AM, Petr Bena <[hidden email]> 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
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
>
_______________________________________________
MediaWiki-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Reply | Threaded
Open this post in threaded view
|

Re: An Administration Page

Svip
On 7 February 2012 16:39, Petr Bena <[hidden email]> 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.

_______________________________________________
MediaWiki-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Reply | Threaded
Open this post in threaded view
|

Re: An Administration Page

David Gerard-2
On 7 February 2012 15:43, Svip <[hidden email]> 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.

_______________________________________________
MediaWiki-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Reply | Threaded
Open this post in threaded view
|

Re: An Administration Page

Svip
On 7 February 2012 16:48, David Gerard <[hidden email]> wrote:

> On 7 February 2012 15:43, Svip <[hidden email]> 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).

_______________________________________________
MediaWiki-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Reply | Threaded
Open this post in threaded view
|

Re: An Administration Page

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


_______________________________________________
MediaWiki-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l