Template talk:Extension

About this board

Archives 

/Archive 1


Automatic fetch of rights not working?

2
Ciencia Al Poder (talkcontribs)

On Extension:TimedMediaHandler the template doesn't display the "Added rights" section. This section is supposed to get populated automatically with the data from Module:ExtensionJson, but apparently it's failing here. And I don't know why.

Pppery (talkcontribs)

It appears that, at one point in the distant past, Module:ExtensionJson contained:

		["AvailableRights"] = {
			[0] = "transcode-reset",
			[1] = "transcode-status",
		},

And it now says:

AvailableRights={
"transcode-reset","transcode-status",},

, which breaks my code that expects the old format. I've fixed it now.

Override link to Packagist?

5
Kghbln (talkcontribs)

It appears to no longer be possible to override the automatically retrieved link to Pagagist with |composer=mediawiki/extension as I tried with this diff. As a result, the broken link is still shown.

Kghbln (talkcontribs)

It turned out that the link I tried to add was a link to some outdated extension fork. However, this brings me to the next issue. There is a link to Packagist even though the extension is not listed on Packagist. Obviously, not every extension with a composer.json file can be installed with Composer. How do I remove the link from the info box?

Ciencia Al Poder (talkcontribs)

Since the information about Packagist is set in the composer.json file on the repository, you'll have to submit a patch and change it to the correct name. Then it will be updated automatically on this page once merged.

Samwilson (talkcontribs)

@Kghbln: The name in that extension's composer.json is mediawiki/openidconnect (i.e. without hyphens), but yeah it's also not registered with Packagist. The fix is as @Ciencia Al Poder says, to remove the name from composer.json — alternately, the package could be registered on Packagist (although probably not under the mediawiki namespace, I think that's deprecated now). @Cindy.cicalese: You could register it under your own namespace on Packagist.

Kghbln (talkcontribs)

In the meantime, even though I am not actively looking for this, I have found another three or four extensions where none of this works, e.g., it shows a link to Packagist even though the extension is not registered there. We need either a way to disable the link to Packagist or someone should go through all repositories and fix the composer files.

Reply to "Override link to Packagist?"

Parameter to indicate dependencies

5
Novem Linguae (talkcontribs)

Is there a parameter to indicate dependencies? For example I discovered during the install process for Extension:CentralAuth that it requires Extension:AntiSpoof, and I'd like to add that to the Extension template. If there's no parameter for this, can it be created? Thanks.

Ciencia Al Poder (talkcontribs)
Novem Linguae (talkcontribs)

"it's already stated in Extension:CentralAuth#Installation" - It's stated because I added it. But the infobox would be a good place for this information too. It is the first place I looked, and is an intuitive spot to list something like that, imo.

Ciencia Al Poder (talkcontribs)

I feel adding this "particular" information won't be too useful because infoboxes are too bloated already. I suggest looking at this nice presentation from EMWCon Spring 2023 about infoboxes.

If we add dependencies on other extensions, are users expected to find there also dependencies on other services? Like Extension:CirrusSearch depends on ElasticSearch. Php extensions, too? This will add incomplete installation requirements with questionable benefit.

Jdforrester (WMF) (talkcontribs)
Reply to "Parameter to indicate dependencies"

Link to bugtracker for non-wmf exentsions?

4
Kghbln (talkcontribs)

It looks like this template is missing the option to like to the bug tracker for non-wmf extensions? If yes, it will be cool if someone could add it.

Jdforrester (WMF) (talkcontribs)

Do you mean, non-Wikimedia-hosted extensions? There are ~190 extensions used in Wikimedia production and ~2000 in gerrit/Phabricator, but you're right that not all of them use that.

Kghbln (talkcontribs)

Yeah, I meant everything that is not in Gerrit and does not use Phabricator, i.e., extensions hosted on GitHub, GitLab, Bitbucket, private Git instances, etc.

Kghbln (talkcontribs)

Triggering this is a new bug report of today in Phabricator for Extension:Semantic_Drilldown, even though GitHub is advertised as the bug tracker. The info is at the very bottom of that page and not in the spot where most people are used to finding the link. We may probably want to help these creatures of habit. I guess I am one of them, too. ;)

Reply to "Link to bugtracker for non-wmf exentsions?"

… defaults to the value of the 'requires' property of extension.json

9
Incnis Mrsi (talkcontribs)

Look at Extension:Echo. The infobox informs that required MediaWiki version is 1.40, because the template fetches the thing from the master branch. But production wikis, in this case, use other branches (releases). Shouldn’t your template be foolproof against showing development versions by default on |mediawiki=?

Ciencia Al Poder (talkcontribs)

With compatibility policy = rel, data from extension.json shouldn't matter, because each branch is created for each release. Minimum MediaWiki version should be added manually to the template, to specify the first MediaWiki version where the extension was available.

For the Extension:Echo page, version was removed by @Kghbln in Special:Diff/5323592. I don't know it this has been removed extensively, though.

Kghbln (talkcontribs)

I believe that the plan here is to document the latest version compatibility of the extension; at least, I have been told so by I cannot remember who it was. Actually, it was different people over time. In the end, I agree since there are always older versions around. You just have to look for them specifically. The existence of them could indeed be specified in a separate field (first MediaWiki version) which we do not have at hand, or perhaps easier, add a note to the existing field indicating that a version compatible with older versions of MediaWiki is potentially sticking around. Before I forget: Yes relying on extension.json is done extensively.

Bawolff (talkcontribs)

I'm not sure having this field in the infobox makes sense at all. Knowing what the master version of the extension supports for mediawiki doesn't seem useful when there are release branches. Maybe we just shouldn't have this field in the infobox.

We don't really have a good story around different versions of extensions. I'm not sure what the solution is.

Ciencia Al Poder (talkcontribs)

MediaWiki version should be hidden when compatibility policy is set to rel or ltsrel. However, I think extensions using compatibility policy of master should have this field visible and populated from extension.json as it is now.

MGChecker (talkcontribs)

I agree with Ciencia here, as a maintainer of extensions with master compatibility policy.

Kghbln (talkcontribs)

It reads like we are getting somewhere. Agree with Cienca's suggestion. While we are at it we could also do this for the PHP requirement.

Jdforrester (WMF) (talkcontribs)

Maybe we should label these fields as "for the current development branch" for clarity?

Incnis Mrsi (talkcontribs)

Better than the current misleading thing. But why don’t show some (pseudo)graphic indicating which (extant) versions of MediaWiki are supported by any branch? This would require fetching extension.json from several branches, of course.

Reply to "… defaults to the value of the 'requires' property of extension.json"
Samwilson (talkcontribs)

@Bawolff: Thanks for adding the new 'Quarterly downloads' figures! Looks great. I think we should link it to a page that explains what the numbers mean and where they come from. It's counting ExtensionDistributor downloads isn't it?

Bawolff (talkcontribs)

Yes, that sounds like a good idea. The data is from graphite which is the same source of data powering the popular list on special:SkinDistributor.

Bawolff (talkcontribs)

After looking through some of the less popular extensions, i'm wondering if quarterly is a big enough sample size. Perhaps yearly downloads would make more sense.

Samwilson (talkcontribs)
Bawolff (talkcontribs)
Samwilson (talkcontribs)

Oh yeah, maybe there's some CI downloads included? That does sound like a large number. There are lots like that! https://packagist.org/?type=mediawiki-extension Although I guess it does include every download of every upgrade too.

There are 326 in Category:Extensions supporting Composer. I don't think all of them actually are registered with Packagist though. (But weirdly, the search results response on Packagist (e.g.) has a 'nbHits' field which is exactly 326! Definitely a different list though as e.g. bluespice/rating isn't on Packagist but has a Composer name.)

Reply to "Quarterly downloads"

Tested with MediaWiki

2
Proactive programming (talkcontribs)

People need to know if the extension has been tested with a mediawiki version. I generally go from LTS version to LTS version and I skip the in between versions. So I would want to know if the extension I used with mediawiki 1.35 will work in mediawiki 1.39.x LTS.

Unit Test Master:

  Unit Test File: myextension/Unit Test Table
  Newest MediaWiki Version: 1.39.x LTS
  Oldest MediaWiki Version: 1.35.x LTS

MediaWiki 1.39.x LTS Status: Tested / Not tested / Tested with issues / Broken MediaWiki 1.35.x LTS Status: Tested / Not tested / Tested with issues / Broken

I personally do not think that we need to do this for every single version. The LTS versions are enough. But my view on this might be due to the fact that I stick with LTS versions and I would expect extension developers to make sure that their extension works with LTS version before worrying about the in between versions.

Samwilson (talkcontribs)

I guess this only applies to extensions with compatibility of 'master', because those with 'rel' are saying that they are tested and do work with the MW versions that correspond to the release branches. I've always felt that extensions with 'rel' shouldn't have their own version numbers, because it just means that it's possible to end up with confusion (or, as is often the case, the version number is rarely updated).

But yeah, a table in the infobox would be good, listing which core versions are supported (either by which extension versions, or just the existence of a REL branch).

Some extensions choose to keep supporting older core versions, and it'd be good if they had a way to specify that clearly.

Reply to "Tested with MediaWiki"

Supported MediaWiki version

11
Tgr (WMF) (talkcontribs)

The template defaults to using extjsonuploader data. That works well in most cases, but not for supported MediaWiki version, where the value in extension.json means the MediaWiki version required for the current (master) version of the extension, while the template field is supposed to mean the oldest supported MediaWiki version (for extensions using the release branch compatibility policy, at least). I wonder if leaving the field empty would be a better default.

Ciencia Al Poder (talkcontribs)

I think it would make sense to use the version information from extjsonuploader data only when the compatibility policy is set to master. Otherwise, the value should be specified manually.

Jdforrester (WMF) (talkcontribs)

The field is almost always meaningless; yes, there's a 10-year-old version of the extension that used to work with MediaWiki 1.12 but no-one is testing it and certainly no-one is supporting it. Maybe we should label the field "minimum MW required by development branch" and have a second field for "oldest currently supported branch" which can be set manually (but only to a non-obsolete version, i.e. minimum 1.35 right now)?

Tgr (WMF) (talkcontribs)

Presumably it was tested 10 years ago when it was used with 1.12; shouldn't that be enough? For extensions following the release branch model, which get snapshotted biannually together with MediaWiki, being able to see how far those snapshots go back is a nice convenience. Someone using an old MediaWiki version presumably doesn't care about support, or doesn't have a choice.

(I can see how the "supported MediaWiki version" terminology could be misleading for something very old that the maintainer, if there's still one, won't entertain fixes for, but that's my mistake, the infobox doesn't use that wording.)

And I don't think using the field for "oldest MediaWiki version for which there is a compatible extension version" would crowd out more useful information - you are supposed to install the extension from the release branch matching your core version, so knowing what older core versions the extension's development branch or latest stable is compatible with seems quite useless.

For extensions using the master compatibility policy, I agree leaving the current behavior (using the extension.json field) makes more sense.

Ciencia Al Poder (talkcontribs)

If the field is entered manually, it's often used to say what's the latest MediaWiki version where it has been tested. For example, unmaintained extensions may have an old value there and not work with the latest MediaWiki versions, or only support LTS versions.

Tgr (WMF) (talkcontribs)

"Latest MediaWiki version the extension is known to work with" is certainly more useful information than any of the alternatives mentioned above. The value pulled from extension.json isn't really useful for that purpose, though.

Jdforrester (WMF) (talkcontribs)

"Latest MediaWiki version the extension is known to work with" is certainly more useful information than any of the alternatives mentioned above.

If "known" we mean "tests pass", then for 99%+ of extensions that's just master.

Tgr (WMF) (talkcontribs)

"Known" would mean "someone tested the extension with this relase". The use case here is that someone adds (via extension.json or directly) something like "<= 1.35.0" (which at the time actually means 1.35-138), then 1.39 is released, drops deprecated features, which breaks the extension – knowing that the extension doesn't work with the latest MediaWiki release would be useful for more users than whether it can be made to work with 1.27 (or at least I'd hope so).

Jdforrester (WMF) (talkcontribs)

Then call it "last manually tested with"?

Proactive programming (talkcontribs)

Continuing this conversation with a new title.

Tgr (WMF) (talkcontribs)
Reply to "Supported MediaWiki version"

Add 'bundled since' parameter

2
Push-f (talkcontribs)

Currently bundled extensions are documented like:

{{Bundled|1.38}}
{{Extension
|status          = stable
...
}}

that is the information that it's bundled is provided via a separate template (Template:Bundled).

The problem with this is that the extension infobox still contains a prominent Download extension link and the note about the extension being bundled on top of the page is very easy to miss (indeed MediaWiki users might be used to just searching the Download extension link in the infobox). So I think it would be better to set this information via a bundled parameter, i.e.

{{Extension
|status        = stable
|bundled since = 1.38
...
}}

This could still add the {{Bundled|1.38}} note as usual but it could also additionally show "Bundled since 1.38" right before the Download link in the infobox.

Ciencia Al Poder (talkcontribs)

I don't think it's necessary to add more notices about bundled extensions:

  • There's no harm in downloading an already bundled extension.
  • Even if bundled, you may want to download it again to receive further updates, like bug fixes that usually don't warrant a new MediaWiki release.
Reply to "Add 'bundled since' parameter"

Version for Wikimedia Phabricator Day 1

1
Qgil-WMF (talkcontribs)