Project talk:WikiProject Extensions

About this board

 Home Discussion Participants Projects Ideas & Requests Workshops Barnstars Templates 
This is a place to share and brainstorm ideas specifically related to WikiProject Extensions and its projects.

Please use the support desk for any MediaWiki software related help inquiries and the current issues noticeboard for discussing issues related to site.

Mark this very wiki project as historical

AKlapper (WMF) (talkcontribs)

Pages like and seem to be old, inactive, unmaintained places with outdated information (e.g. colliding workflows from 10 years ago about "extension review"). However there is no obvious sign of that, so readers who end up on these pages might be misled. Is my impression incorrect? If not, does anyone have thoughts how to proceed in such cases? Add a "historical" template? Redirect? (Heads up to @Varnent as the original author.)

AKlapper (WMF) (talkcontribs)

No reply; marked as historical in 49 edits; more info in phab:T301984.

Reply to "Mark this very wiki project as historical"

Cascades of Extension documentation?

BAMaustin (talkcontribs)

At each stage of creation for a new/updated extension, documentation is created. Then a derivative is recreated at the next stage. The recursive documentation burden could be relieved with a cascade of documentation automation.

With documentation built into the source code in a GitHub Pull Request for an extension, a tool like Sphinx can generate a GitHub markdown document.

The GitHub extension for MediaWiki can reformat that for inclusion in MediaWiki. (or use the

You'd want something like the MediaWiki template:extension to auto populate and insert into the a reconstituted Sphinx-generated content.

For our MediWiki documentation site... that was established in March 2007... we also want to integrate MantisBT bug management extension and the Discourse forum for support. (But updates to our site for the necessary Lua prerequisites have been... less than successful. So we use a more simplistic pre-Lua template.)

The documentation ecology is being further integrated with a extension to Discourse that auto-posts back to Pull Request threaded messages.

But all of this would be predicated on initial code having some internal documentation & the Pull Request submission triggering a cascade of documentation creation/synchronization. So I suppose it all start with the Extension API documentation.

An integrated look at flowing documentation through extension evolution should be outlined (if not explicitly defined, streamlined or automated) in this discussion: "blue sky" idea for an "extension" is floated, idea formally proposed, requirements specification, design, proof of concept, alpha test, revision, beta test, installation docs, user docs, public release, support, bugs & enhancements, incremental release cycle, obsolescence, retirement, archiving.

Much of the documentation should only be written once. But if there isn't a What to cascade the data, it may be written at each stage... creating an unbearable (and all-too-often, dodged) burden.

Reply to "Cascades of Extension documentation?"

Ask new extension into frwiki

Bouzinac (talkcontribs)
Taavi (talkcontribs)
Reply to "Ask new extension into frwiki"

What happens after i join?

Johnywhy (talkcontribs)

i clicked join on this page, and added my name. Does that trigger any further action besides adding my name to this page? What's next?


Reply to "What happens after i join?" (talkcontribs)

I am going through the wiki installation and want to add extensions i think it would be good when the link at the front-page leads to a tutorial about extensions instead to the developers place.

This post was hidden by (history)
Reply to "extension list"

Convert this to a MediaWiki Group?

Qgil-WMF (talkcontribs)
Reply to "Convert this to a MediaWiki Group?"
Seb35 (talkcontribs)

Hi, I collected some statistics about the number of extensions (various figures from different sources) and their quality (mainly using categories here on Are these statistics interesting from your point of view? if so, some script could be written to automate the process.

Do you see other figures, which could be interesting? I have some idea that the number of extensions with automated tests would be interesting (it’s a sign of very good health for an extension to have such tests), but I don’t think there is an easy way to create this number. A further step could then to have the number of extensions, which pass (e.g.) 95% of automated tests with MediaWiki last version.

DanielRenfro (talkcontribs)

Very interesting; thanks Sébastien!

I have no use for these numbers (but then again WMF or might have a use,) but they are interesting. Almost 150 extensions used on WMF production sites - wow! I'm glad to see such a thorough overview of the extension landscape.

Reply to "Statistics about extensions"

Git submodules, subtree, or symlinks?

Negative24 (talkcontribs)

I have a MediaWiki installation that I want to keep linked to the mediawiki/core branch so that I can keep updated with the code. That MediaWiki installation would be used for testing of my extension that I'm writing which would be written in the regular /extensions/MyExtension directory but I would also like to use a local git repo to keep track of my extension's changes. Should I use git submodules, git subtree or symlinks so that I have a git repo in my /extensions/MyExtension as well as the mediawiki/core? What do you use/recommend? Thanks,

Seb35 (talkcontribs)

To write and live-test my extension, I have a symlink from core/extensions/MyExtension to my extension directory, but you can also `cd core/extensions; git clone /your/extension/MyExtension` if you want to keep control of the deployed version. You can be interested by MediaWiki-Vagrant (I cannot give advices with that, I didn’t succeed in installing it).

GregRundlett (talkcontribs)

There is a .gitignore file in mediawiki/extensions/ that ignores everything in 'extensions' so MyExtension will not "interfere" at all with updating your core checkout.

If your extension is brand new and you aren't hosting the code anywhere (meaning there is no "remote" for your code), just create a git repo in your project folder itself. ie.

# create a MyExtension directory in the extensions/ folder.  
cd path/to/core/extensions
mkdir $MyExtension
cd $MyExtension
# hack hack hack
git init .
git add . -m "initial commit of $MyExtension code"
# hack hack hack
git commit -am "some more improvement, getting close to feature complete"

Later, when your extension is ready to be published, you can add a remote to your $MyExtension and push it there (including if you want to host there and follow guidelines) I believe you would only use a submodule if $MyExtension were to be deployed with a specific release of MediaWiki proper.

If you want to develop $MyExtension against a specific release of MediaWiki, then after cloning core, checkout the branch you desire.

Reply to "Git submodules, subtree, or symlinks?"

Unanswered question

Chaosdruid (talkcontribs)

Hi all

I am unfamiliar with how media-wiki support works. I believe I posted in the right place but, as questions there seem to go unanswered for quite some time, I thought maybe someone here could point me to where I can ask for the info?

Original question


Qgil-WMF (talkcontribs)
Reply to "Unanswered question"

Concerning; Conflicts of Project Management

Habatchii (talkcontribs)

This inquiry is directed towards the Dispute Resolution committee(s) of this and other WikiMedia sites.

Accordingly; I recent signed on as a member of the 2012 Extension Page Review Drive project here on the mediawiki site, under the direction of User:Varnent and proceeded nonchalantly and without bias intent to try new extensions, reporting 'some' of those that did not work with MW1.19. I had positive results until approached by User:Jasper Deng who did accuse me of a gross misrepresentation (see; Concerning; Extension:SecurePoll).

There is an obvious conflict of Project Management in this case. I do not have any legal issues with the aforementioned editor, nor the original author of the extension(s) in question. I only intended to notify other editors and users that the published version was not completely cited for useability by using site authorized templates.

In addressing the editor's usage of Wikipedia material, there are more conservative than accusations being drawn.

Please consider establishing a new Project Resolution process to avoid possible edit conflicts. Such a resolution may include a new showcase project for system or featured extensions, so reducing unsolicited traffic, notification for project members and providing administrative overhead for developers.

Disciplinary reliefs will not be sought in this matter.

Reply to "Concerning; Conflicts of Project Management"