Handling the "MediaWiki Manager Extension Store"

[Yaron Koren]

Hi everyone,

In case you missed yesterday's meeting, Lex gave a very interesting demo of functionality he recently added to his "MediaWiki Manager": an "extension store", which lets people download, install and uninstall extensions from the command line. I don't know if there's an easy way to see it in action, but thankfully I think just today Lex helpfully put up this screenshot of what the functionality looks like now:

https://github.com/dataspects/mediawiki-manager/blob/main/images/mwmscreenshot.png

This is a "dashboard" sort of interface with a bunch of elements, but the important one is the little section called "Extension Store".

As I noted to Lex at the time, this is potentially an extremely useful piece of functionality, one that people have been talking about creating for years now - Jeroen had a Google Summer of Code project to create essentially this functionality, back in 2010:

https://www.mediawiki.org/wiki/Google_Summer_of_Code/Past_projects#Extension_management_platform

I think there are some interesting conclusions there about waiting for functionality from the Wikimedia Foundation vs. doing things ourselves, given that this sort of feature has been discussed for over 10 years now, and Lex managed to create this functionality in (I think) a few days. That's not what I wanted to talk about, though. My general question is: should this be a part of the "Canasta" Docker image functionality? My view is no - I believe this should be a separately-released and -maintained utility, which should be available to any administrator, not just those that got their MediaWiki installation through Docker - 

I thought about just sending this email to Lex (Lex, you might well agree with what I'm saying), but I figured it would be worthwhile to talk in general about the scope of Project Canasta. Should it directly include utilities like this? Or should any such utilities live separately, and just be brought in by Docker?

For that matter, if anyone has any opinions on this specific functionality, that would be interesting to talk about as well. The fact that it is meant to rely on a central, vetted list of extensions is definitely an interesting aspect of it, which has some "pros and cons".

-Yaron

--

WikiWorks · MediaWiki Consulting · http://wikiworks.com

[Lex Sulzer]

Hi Yaron

I fully agree with you that all the functionality depicted in https://github.com/dataspects/mediawiki-manager/blob/main/images/mwmscreenshot.png should be released as a separate functionality to be used with any MediaWiki setup.

A wiki managed by "dataspects MediaWiki Manager" (DSMWM) doesn't need any adaptations or extensions for this to work. DSMWM only interacts with the MediaWiki root folder (through shell scripts wrapped in PHP) and the MediaWiki API.

Right now I am able to showcase the rudimentary implementations of these 3 primary use cases:

1. Enable (install) and disable extensions
   
2. Take restic backups
   
3. Upgrades
   

I am now about to address security, idempotency and rollbacks.

Regards

Lex

[Cindy Cicalese]

I agree that it is very useful and unlikely to be developed by the Wikimedia Foundation at least any time soon. I also agree it should be separate functionality from the Dockerized environment - although it could perhaps itself be delivered in a container. But, I will note that there will be a dependency between the two products, as they need to agree on a configuration file structure and file system layout. Also, the Apache container would need to be able to volume in the files for the extension store in a flexible manner (i.e. not requiring the admin to edit the docker-compose.yml file directly). Also, it would be beneficial if there were a common authentication approach between the two products.

Cindy

--
You received this message because you are subscribed to the Google Groups "Project Canasta" group.
To unsubscribe from this group and stop receiving emails from it, send an email to project-canas...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/project-canasta/318fb77e-bb2e-439a-bf7a-fb9fdabec061n%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ad Strack van Schijndel]

Indeed this would be great to have. 

What I'm wondering is how you manage extension settings and interaction between extensions.

Do you have ideas about that?

---

From: project...@googlegroups.com <project...@googlegroups.com> on behalf of Cindy Cicalese <cin...@gmail.com>
Sent: Friday, February 26, 2021 15:36
To: Lex Sulzer <l...@dataspects.com>
Cc: Project Canasta <project...@googlegroups.com>
Subject: Re: Handling the "MediaWiki Manager Extension Store"

 

To view this discussion on the web visit https://groups.google.com/d/msgid/project-canasta/CACxQaDzX5ZrYzwbFySM__CT8gc094m4rw0Paptawb5%3DBA22Uzw%40mail.gmail.com.

[Yaron Koren]

  Hi,

Lex and Cindy - I'm also glad you both agree that this feature should be part of a separate product. Lex, I'm looking forward to its release! I wouldn't be surprised if it improves life for a lot of people.

Cindy - I'm not sure that there has to be any dependency between these products. But we should talk about the structure (which I think is what Ad was asking about too). The way the "extension store" thing currently works, I believe, is that it directly modifies LocalSettings.php - adding wfLoadExtension() calls when a new extension is downloaded/installed, and then either removing or commenting out those lines when extensions are deleted/uninstalled. What I think it should do instead is have its own settings file. So, if this utility were called "Strudel", it would have its own file, StrudelSettings.php, which is where all the changes would be made - and then LocalSettings.php would have a line like "include_once('StrudelSettings.php');".

I am now talking about having four different settings files: LocalSettings.php, MyBeforeSettings.php, MyAfterSettings.php, and now "StrudelSettings.php". This seems like a lot, and it is potentially confusing, but it also keeps things very well organized: each file has only one owner/modifier, so that if, for example, the main Docker image is updated, neither the admin's custom settings nor the "Strudel settings" will get erased.

I have previously argued that, in addition to the regular MediaWiki /extensions and /skins directories, there should be /myextensions and /myskins directories. (Or something like that.) Does that mean that there should also be /strudelextensions and /strudelskins directories? I would say: yes. Again, it's the easiest way to guarantee that no system causes problems for any other system. And the admin might not need to be aware of all the "Strudel" stuff in the file system, anyway - they might only interact with the application through the web interface.

Cindy - authentication (i.e., making sure that only people who are allowed to access the "extension store" can do so) is a challenge. It's especially a challenge if Lex's "MediaWiki Manager" (which I like to call "Mwanagenzi"), the thing that handles MediaWik installs, upgrades and backups, has its own web interface - which also requires its own authentication. I don't know if anyone has any thoughts on how best to handle that - for either system.

-Yaron

To view this discussion on the web visit https://groups.google.com/d/msgid/project-canasta/AM9P190MB13303A139ACE63BCF81C1FC0DA9D9%40AM9P190MB1330.EURP190.PROD.OUTLOOK.COM.

For more options, visit https://groups.google.com/d/optout.

--

[Yaron Koren]

Actually, I want to follow up on the authentication thing. Lex (or anyone else) - is there any easy way to have the web interface(s) for these MediaWiki management tools only be accessible for people with admin privilege? The only way I can think of is just to have the username/password for the web interface (or maybe just a password) be set in LocalSettings.php. Which sounds like a hack, but maybe it's not so bad.

[Cindy Cicalese]

The authentication for the management tool would have to be independent of the wiki or else mis-configuring the wiki using the management tool could prevent you from logging in to the management tool to fix the wiki. I believe that Lex used Gatsby to build the management tool. More information about authentication with Gatsby is at https://github.com/gatsbyjs/gatsby/tree/master/examples/simple-auth.

[Yaron Koren]

Well, that's true about being independent of the wiki. A better approach than using LocalSettings.php would be to have a settings file just for the management tool, which would hold the username/password and maybe other settings too. (I can think of a few other useful settings - one could be a URL to set who is the "curator" for the list of approved extensions/skins, but that's another story.)

Could you (or anyone else) explain the Gatsby authentication approach, in simple English?

[Lex Sulzer]

The question of how "integrated" the user management should be is TBD. I have earmarked this aspect under https://mwstake.org/mwstake/wiki/MWStake_MediaWiki_Manager#MediaWiki_Manager_UI.

I'm looking forward to investigating this point!