Talk:Requests for comment/Distribution and deployment

Wordpress

I notice that Wordpress has a really nice extension (aka "plugin") management system; maybe that would be good to use as an example. Tisane 04:54, 25 May 2010 (UTC)

Thanks for the suggestion :) It indeed has a very nice system (from the users point of view anyway), and I'm planning to have a good look at it. Do you know any high level developer docs on this though? I have not been able to find any, and have heard some rather bad things about how easy it is to reverse engineer wp...

-- Jeroen De Dauw 10:37, 25 May 2010 (UTC)

Perhaps you'll want to check out pages such as http://codex.wordpress.org/Developer_Documentation and http://codex.wordpress.org/Function_Reference#Action.2C_Filter.2C_and_Plugin_Functions, if you haven't already? I wasn't thinking so much that you would want to try to cannibalize actual code, but rather that the concepts could be replicated with MediaWiki. This actually doesn't strike me as being a particularly difficult project, by the way. Isn't it just a matter of inserting/deleting/modifying lines of code in LocalSettings.php through a web-based interface? Oh, and I guess searching for and downloading extensions, and keeping track of all the configuration parameters. OK, that could be a pain in the neck. Tisane 12:47, 25 May 2010 (UTC)

Reading more carefully over this page, I see that you had already mentioned Wordpress. Great minds think alike! Tisane 12:48, 25 May 2010 (UTC)

Thanks for the pointers :)

I don't think the goal of this project is easy to achieve. The concept is simple, actually implementing it with MediaWiki is not. Otherwise it would have happened long ago.

-- Jeroen De Dauw 16:25, 25 May 2010 (UTC)

Yeah, you're right. Sorry, I didn't mean to minimize the magnitude of the work you're doing. Tisane 16:50, 25 May 2010 (UTC)

Perhaps another useful resource would be /wp-admin/includes/ -> plugin.php at http://phpxref.ftwr.co.uk/wordpress/nav.html?_functions/index.html Tisane 14:07, 26 May 2010 (UTC)

Standardization of extension data

If we're going to emulate the Wordpress model, the wiki owner should be able to search for plugins by keyword, author, or tag. An extension matrix is already automatically generated by a bot, but as you can tell from looking at that matrix, the extension data on this wiki is not in a sufficiently informative and standardized form. E.g., some extensions are lacking basic data, or have it only in the text and not in the infobox. A way is needed to make it sufficiently informative and standardized and keep it that way. I'm thinking that a bot could be used to detect such issues and automatically tag extensions as being not in compliance.

Following up can be done either similarly to WildBot (i.e. simply putting a notification template on the article talk page and then removing it when the issue is fixed) or more aggressively, by putting a message on the author's talk page. The author could be identified using the infobox, or, if the author info is not available there, the bot could look at the page history and contact the person who created the extension page. Since not everyone checks their MediaWiki.org watchlist regularly, an email might be sent if, after the notification is posted, they don't make any edits to MediaWiki.org within a certain time (say, a week). Ideally, we will want to contact these authors right after they make the edits; therefore, a bot that checks the MediaWiki.org RecentChanges IRC feed (if such a thing exists) and responds immediately to these issues would be good. We might also use Extension:Semantic Forms to encourage the filling out of basic extension info.

How might tags be generated? Categories could be used for that purpose. E.g., everything in Category:Facebook extensions will get the "Facebook" tag. Since some categories have subcategories, these categories should be recursively crawled in order to obtain these tags. The category pages themselves could include an infobox or Semantic MediaWiki item noting the appropriate tag that the extensions in that category should go under.

What about keywords? There should probably be a standardized list of keywords, much like what Bugzilla uses. The list will be editable, but if a keyword deviates from what is in the list, then the bot will automatically flag it as non-standard and follow up. Template:Extension can be revised to have keyword1, keyword2, etc. just like it currently has hook1, hook2, etc. Maybe a similar_extension1, similar_extension2, etc. item should also be added.

I'm going to try to get SMW onto mw.org, which would allow for querying the extension meta data, and developers to easily edit it. Some work would be needed to create a specialized querying tool for this, that should not be to hard though. A separate channel would still be required for things such as rating extensions, but that is not required for the initial version anyway.

--Jeroen De Dauw 17:52, 26 May 2010 (UTC)

Extension:ExtensionDistributor should collect statistics on how often each extension is downloaded, and/or reliable means of assessing how many wikis use an extension should be used to determine an extension's popularity, so that the interface can flag certain extensions as being popular. SVN should also provide information on new and recently updated extensions. Wiki owners should also be told by the interface if an extension is experimental, beta, etc. and if it has any significant known problems. E.g., Extension:FBConnect is not really something a wiki owner should install at this time, unless he is willing to do some troubleshooting and/or development on it to work out the kinks. Maybe there should be an extension rating system as well (e.g. 1-5 stars).

The extension manager should compare the MediaWiki version of the present installation to the versions that are compatible with the extension. Thus, if the user has MediaWiki 1.16, and the extension is known to not work with anything later than 1.14, the user should be apprised of that fact, or the extension should be filtered entirely out of the search results if the user elects to do so. This project should also be done in conjunction with a switch to a totally web-based upgrading functionality replacing the need to run update.php from the command line. Basically, all need to manually edit or download files, after the initial download of the software, or to run anything from the command line, should be utterly eliminated. Tisane 13:18, 26 May 2010 (UTC)

Dependency handling is indeed planned. I don't agree that extensions that are not compatible with your installation should simply be omitted. Compatibility should simply be a factor in the related extension ranking algorithm. When viewing such an extension, it should ofcourse clearly indicate it's not compatible, and have the installation button disabled.

--Jeroen De Dauw 17:52, 26 May 2010 (UTC)

The deployment framework comes with dependency checking - this was actually the main reason for implementing it since nobody wants to spend time for browsing dependency graphs... I am going to ask Kai to post some info here. --DanielHansch 12:25, 10 June 2010 (UTC)

Recommendations

So far so good on the roadmap!

I'd tend to recommend keeping the metadata in the plugin file(s) rather than making it totally wiki-side, which has several advantages:

• Setup and configuration can still work with things that aren't in the central database, such as in-development work and custom plugins.
• Plugins that aren't on the main mediawiki.org repository could still refer to their own sources of code updates
• Primary repository on mediawiki.org can still be a default place to search for new plugins, but could be safely disabled (for instance if it's not reachable through a firewall)
• A plugin repository simply needs to scan the information available in its plugins, avoiding problems where the code is updated and the entry isn't, and making it easy to create a local repository of particular desired plugins.

For configuration, I'm definitely a fan of an approach that adds a db-backed, cache-friendly local configuration database which new code can use, rather than trying to store existing $wgWhatever settings. (Though making it easy to specify backwards-compatible global variable names might be really helpful for uptake -- we could move existing code over a lot faster, and in many cases not have to change deployed configuration files.)

-- brion 21:34, 2 June 2010 (UTC)

Installation of content

I am wondering why nobody is requesting a feature which allows selecting and deploying not only extensions but also content, i.e. collections of articles. This is especially useful in Semantic MediaWiki-environments. Why that? SMW-users (knowledge architects in the ontoprise lingo) starting with a fresh installation are often faced with a blank page problem. They start building a wiki application which serves a particular need, e.g. a timetable with events for a team of co-workers, a list of hotels including a map and personal rating info and the such. Building a wiki app means preparing the datamodel, programming the templates and forms and building nice example articles to teach others using the app. An efficient knowledge architect should be able to say: well, this is a standard app which somebody else has already prepared! If I could simply download it, merge it with what I have in my installation and adjust it a bit then I am done! This is exactly what the deployment framework does :-) Does anybody believe that this is requested by MediaWiki-users?

--DanielHansch 13:00, 10 June 2010 (UTC)

Thanks for the suggestion :) Although I had not thought of it myself before looking at the deployment framework, I think it's a great feature to have. As I'm building upon the DF, and see no reason to get rid of this feature, I'll retain it.

-- Jeroen De Dauw 15:03, 10 June 2010 (UTC)

Great idea. I for one would like to see some standard documentation-page packages. Could we set up a 'blank' wiki to contain nothing but documentation that can then be 'bundled' onto another wiki?

--Dmb 08:21, 15 June 2010 (UTC)

Hi there,

we already provide user manuals in a package which can be deployed with the halo deployment framework (the user manuals are stored in the HElp: namespace ofcourse). I suggest that you take a look here at the User Manual Extension. Please let me know how it worked out!

greetings --DanielHansch 21:10, 17 June 2010 (UTC)

Testing?

I think each extension should come with a /Testing page, where some tests can be written in order to allow automatic testing of the installed code. See Testing portal.

--Dmb 08:18, 15 June 2010 (UTC)

This would indeed be very useful to have. I will hold this feature in consideration as I work on my project.

-- Jeroen De Dauw 12:53, 15 June 2010 (UTC)

Extension conflict sets

The problem: A reasonable management system will probably need a way to declare an extension as conflicting with others. All visual editing extensions should probably conflict with each other, but it is impractical for each extension to list all the other editors.

A possible solution: Each developer could tag his/her extension as an "alternative-editor". The management system will allow only one "alternative-editor" to be installed at a given time. Of course, the tag mechanism should be generic.

As a nice bonus, users could be shown alternatives for the extensions they have installed. Developers could receive suggestions for tags/conflicts based on their hook usage.

The truly awesome solution, of course, would be to allow installing many alternatives and leave the choice to each user, though this might be out of the scope of your project. --Arcturus4669 18:19, 15 June 2010 (UTC)

What I will do here is attempt to use existing information (like in the extension matrix), provide a way for extension devs to specify compatibility, and also allow users to "vote" on compatibility. The later one will probably not be for the first version, but is definitely neat, and currently used by WP.

Jeroen De Dauw 02:28, 7 July 2010 (UTC)

New developments?

Any new developments on this project? Would love to see this functionality added to MediaWiki. --Varnent 03:55, 14 July 2011 (UTC)