Template talk:Extension

Archives

/Archive 1

Previous page history was archived for backup purposes at Template talk:Extension/LQT Archive 1 on 2015-07-10.

In Extension:PieceOfCode I gave the readme parameter a value, but it just appears as an unidentified link under Download. I assume the same is true for changelog. The easy fix would be to provide link text for each, same as "Browse source code"

But with all these links, you're not downloading anything., so none belong under a Download column! They're just links to files that probably reflect the latest code, and the infobox seems to conflate this with "snapshot". It seems there should be a separate infobox section for Project, with links in it for browse source, view changes, readme, and changelog.

Agree, although many of those links are generated by templates ({{SourceForgeDownload }}, in that example), which would make it difficult to break into different sections

When browsing extensions, I've repeatedly wanted to click the MediaWiki supported version number to remind myself of where it lies in the sequence, what features it provides, and if it's an LTS release. Checking the version with a quick link here would be very helpful.

It would be useful if there was a "main author" parameter, in case there are mutille authors, and a username is provided.

The problem is that the

{{{username}}}

parameter is usually populated with the main author's username. it displays it after the

{{{author}}}

parameter. If there are multiple authors, it shows after the last one. However, usually the main author is put first, so the username will show at the end.

It's 300.

in the documentation => imagesize Facultative, size of the image without adding px, e.g. 360 (default size is 300px) in template data => "imagesize": { "default": { "en": "220" } } .Thanks. --Christian 🇫🇷 FR (talk) 13:15, 4 April 2024 (UTC)

It's 300. I fixed it. Thanks!

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.

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.

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.

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?

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.

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

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.

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.

That's an installation requirement, and it's already stated in Extension:CentralAuth#Installation, I don't feel like this should belong to the extension infobox.

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

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.

Yes; perhaps this should be on Template:ExtensionInstall (and CA's now-updated page – Thanks @Novem Linguae! – switched to use that template)?

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.

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.

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.

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. ;)

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=?

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.

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.

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.

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.

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

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.

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

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.

@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?

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.

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.

I've created a section at Manual:Extensions#Popular_extensions. Manual:Installing extensions redirects to that page, so it seemed appropriate.

And yeah, maybe annual would be better. Also, we could probably retrieve Packagist stats too and add those for Composer-installable extensions.

Oh i didn't even think of packagist, although I'm not sure if there are enough composer extensions to make it worth it.

I'm also a bit doubtful of some of their stats. I just find it hard to believe that Semantic MediaWiki has been installed 240,000 times - https://packagist.org/packages/mediawiki/semantic-media-wiki/stats

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