Template talk:Extension

Jump to navigation Jump to search

About this board

Archives 

/Archive 1


Can we get an "unavailable" or "unreleased" or "forthcoming" status

3
Summary by Florianschmidtwelzow

Extensions, which code is not yet available, should not be listed on MediaWiki.org.

2601:5CD:C200:9BE0:DC21:FD9B:A847:36B3 (talkcontribs)

For extensions where we don't have the code yet?

Pppery (talkcontribs)

These shouldn't be posted to MediaWiki.org until the code is available.

Kghbln (talkcontribs)

I agree with Pppery.

Add short disclaimer about version

1
André Costa (WMSE) (talkcontribs)

Since the data is now taken from extension.json which reflects the master branch the data will almost always be ahead of whatever version is declared in "latest version". A short tooltip on values taken from extension.json or a general disclaimer in the bottom of the template would be useful to avoid any confusion

Reply to "Add short disclaimer about version"
Rehman (talkcontribs)

Would be nice if we have a parameter like "Used on Wikimedia projects", which lists the Wikimedia projects that use the extension (i.e. enwiki, itwiki, etc). Yes it is slightly unrelated, but it gives a good indication of matured/vetted extensions.

Ciencia Al Poder (talkcontribs)

Being used on Wikimedia is an indicator already of the matureness of the extension.

Rehman (talkcontribs)

Yes. Hence the reason why such a parameter could be useful.

Majavah (talkcontribs)
Rehman (talkcontribs)

Thanks. Tbh, I forgot about that template. Maybe we could merge that into a parameter of this infobox for neatness? Just a suggestion.

Ciencia Al Poder (talkcontribs)
Reply to "Used on Wikimedia projects"

Getting mediawiki from extension.json

10
André Costa (WMSE) (talkcontribs)

I tried to get the template to get the |mediawiki= parameter from extension.json. Since I didn't want to try it live I implemented it in Module:Extension/sandbox then tried to preview it here by replacing {{{mediawiki|}}} with {{#invoke:extension/sandbox|getMediawiki|{{{mediawiki|}}}}}. But it looks like the sandbox isn't loaded so not sure how to test this before going live.

Tacsipacsi (talkcontribs)

If you replace

</noinclude><includeonly>{{#switch:<translate></translate>

in the third line with

</noinclude><includeonly>{{#switch:

the result looks awful, but at least it depends on what in Template:Extension is rather than what in Template:Extension/en is. (Don’t forget to revert this change before saving!) However, I’m not sure if reading the MediaWiki requirement from extension.json would be appropriate—extension.json in master lists what master is compatible with, while (IMO) the infobox should list what MediaWiki version any of its versions is compatible with.

André Costa (WMSE) (talkcontribs)

Thanks! Tested and {{{mediawiki|{{#invoke:extension|getMediawiki}}} should do the trick once the issue below is resolved.

With regard to the infobox reflecting master. By already now fetching most of the parameters from the extension.json the template already only reflects master (unless manually overridden). I.e. if a user right is dropped/added between the latest release and master then the infobox will update to reflect that. I'd say it's only natural that the mediawiki parameter follows the same default.

Tacsipacsi (talkcontribs)

Naturally an infobox can’t list all versions of configuration variables, hooks, user rights etc., as that would occupy a lot of space. However, listing an earlier MediaWiki version doesn’t, so it’s feasible, and I think it’s worth it, as a potential user is more interested in whether any version of the extension is compatible with their MediaWiki than in whether master is compatible. (By the way, listing user rights is useful, but I’m not sure whether listing used hooks and variables—without any explanation—makes any sense in the infobox. What’s the practical use of these kinds of information?)

Pppery (talkcontribs)

Hah, I'm not the only one who was very annoyed by the difficulty of testing changes to translatable templates: You can work around the problem by replacing #invoke:Template translation with #invoke:Template translation/sandbox, which uses the code I wrote in Module:Template translation/sandbox. I should probably request that that code be merged to Module:Template translation, but never get around to it. Also, I agree with Tacsipacsi that this may not be an appropriate thing to automate (as I wrote on phab:T222479,

The "MediaWiki" key can't be supported because most WMF maintained extensions use backward-compatibility branches, and the module only contains data from the master branch.

)

Tacsipacsi (talkcontribs)

Wow, thanks! I tested Template:Hubs/sandbox just a few days ago, and was very satisfied that I haven’t broken anything—until I realized that the test cases in the documentation actually used the non-sandbox version… Now I added {{\sandbox}} to it. I’m glad we can always come up with new hacks to support Translate (like this one or {{#switch:<translate></translate> or c:Module:Caller title)—although I’m not particularly happy that we need to do so…

André Costa (WMSE) (talkcontribs)

Personally I don't see it as any different from overriding any other parameter. I.e. if the infobox today has a manually entered value then keep that, if not then get it from extension (because some info on version limitations is better than none).

I think the Hook listings are mainly used for categorising the extension page.

On a separate note there should probably be a small remark next to the version field that the info in the infobox need not reflect that version any more.

Tacsipacsi (talkcontribs)

I.e. if the infobox today has a manually entered value then keep that, if not then get it from extension (because some info on version limitations is better than none).

That’s fair, but we need to make sure that people won’t throw out existing parameters like what happens now with other extension.json-backed ones, as well as suggest filling out the version parameter in new/revised infoboxes (as opposed to hooks and the like).

Jdforrester (WMF) (talkcontribs)

I disagree; I think documenting the current reality is much more helpful for people.

Tacsipacsi (talkcontribs)

Whom do you disagree with? What do you mean by “reality”? Both the oldest supported version is a kind of reality (that is where you have a chance to install the extension), and the version supported by master is a kind of reality (that is where any eventual bugs have a real chance to be fixed).

Reply to "Getting mediawiki from extension.json"
Tacsipacsi (talkcontribs)

Currently many extension articles specify |needs-updatephp=no (i.e. maintenance/update.php doesn’t need to be run, because the extension doesn’t make any database changes or whatsoever), while many others do not. This information can be inferred from the extension.json file (for extensions that have this) by Module:Extension, but—to be on the safe side—the module outputs nothing if the answer would be “no” (just like when it doesn’t know anything about the extension). The current mixed situation is clearly inferior; the question is whether we want to include “no” for all extensions it’s known to be no, or we want to omit them, and display anything only if update.php does need to be run. I have no strong opinion on the question, just want to have it decided either way. (I saw related edits by Pppery and Shirayuki, what do you think?)

Pppery (talkcontribs)

As I said on my talk page, I personally don't see the point of setting it to no; running update.php unnecessarily does no harm, and I suspect if a page is silent on whether it should be run, the typical uninformed user would not run it.

Kghbln (talkcontribs)

I think that we do not need to set "No" for this template argument for the simple reason that this is not set consistently over all extensions documented anyways. Moreover you would run into even bigger confusion if it says "No" even though it shoult be "Yes" (See the issue described in this topic). So rather not set it at all than having an potentially incorrect information.

Pppery (talkcontribs)
Reply to "needs-updatephp = No"
Kghbln (talkcontribs)

.. not loaded reliably via "extension.json". I guess because something was not specified correctly in the respective extension's file. Until this is fixed we do need to add this information again. Since it appears that this information was now deleted unconditionally in masses we could have run in documentation issues like the one I fixed for External Data

Pppery (talkcontribs)

This bit of autoloading has actually existed since 2018, and was originally added by Bawolff. It works by checking if the extension defines the LoadExtensionSchemaUpdates hook in extension.json.

Kghbln (talkcontribs)

This means that this field cannot reliably be filled since this particular extension does not use this hook...

Bawolff (talkcontribs)

I always assumed we would keep manually specifying for exts that cant be autodetected or arent in gerrit.

Pppery (talkcontribs)

So, what's happening here is that I erroneously assumed that the code would work for every extension that is in Gerrit and uses extension registration, and thus batch removed all information that could be loaded from the repo whenever I noticed that the hooks (or, occasionally, other loadable information) were outdated. It appears that assumption was incorrect, and I'll try to be more careful if I do that kind of cleanup again.

Pppery (talkcontribs)

I've looked through all 216 pages recently converted by myself or Shirayuki to load stuff from extension.json, and re-added information that shouldn't have been removed to about 15 of them. In four cases (DataTable2, AccessControl, ImageRating, WikibaseMediaInfo), this was |needs-updatephp=yes, and in the rest of them it was other information that probably should be in extension.json in the repo, but isn't.

Reply to "needs-updatephp = Yes"

Auto-updating based on extension.json

4
Bawolff (talkcontribs)

Just a heads up, I recently created a bot to auto-update Module:ExtensionJson, and want to experiment with auto-filling this template out based on extension.json data.

Sophivorus (talkcontribs)

This is probably the only way to really keep extension info updated.

Pppery (talkcontribs)
Pppery (talkcontribs)

Yes Added to the template.

Reply to "Auto-updating based on extension.json"

How to add more than one Author

2
Lucamauri (talkcontribs)

The field dedicated to Author is named Author(s) so it seems it is conceived to host more than one name. Unfortunately nowhere in the documentation is explained what the syntax is. Also, by looking at the code, I see no obvious way to do it. Anyone can explain how this should work? Thanks

Kghbln (talkcontribs)

When using "author" and "username" in combination you can only add one author. To circumvent this issue you only fill "author" like it was done with this diff on RecentActivity.

Reply to "How to add more than one Author"
Jeblad (talkcontribs)

The status ladder seems slightly odd. The one I'm used to follow is the w:Debian style Experimental, Unstable, Testing, Stable, Oldstable, and Oldoldstable. The ladder this template use is unstable, experimental, beta, stable, unmaintained, archive, and unknown. Some of the states are clearly not similar, but the initial ones can give rise to quite worrisome misunderstandings. An extension flagged as unstable in Debian is way better than experimental, but unstable in this scheme is simply broken.

The term beta is also troublesome, as it relates to the release cycle. Typically a release cycle consists of alpha, beta, and release candidate. The status of the extension sets the limit for the final release quality, but it is not part of the release cycle. I believe the term beta should be removed. [Note that IBM use the alpha, beta, and release candidate for the w:Software release life cycle.]

Either the status ladder must be marked as non-standard, or the status ladder must follow an established standard. If it follows an established standard, then I would vote for using Debians status ladder.

Ciencia Al Poder (talkcontribs)

I don't think debian style ladder is useful here, since that applies to versions of a release, and not the current status of an extension

Jeblad (talkcontribs)

Versions of a (pre)release is (or should be) alpha, beta, and release candidate, while status is (or should be) Experimental, Unstable, Testing, and Stable. You can have several releases without ever changing the status.

Still what is really bad with our status ladder is our use of unstable as broken. That creates a lot of confusion.

Ciencia Al Poder (talkcontribs)

Ok, so let's not give them status name for now and just collect all the possible or interesting status:

  • Extensions that are maintained and kept up-to-date with the release lifecycle of MediaWiki, with no expected breaking changes.
  • Extensions with very active development that expect breaking changes as new features are being added.
  • Unmaintained extensions that are kept up-to-date by volunteers but there's no official maintainer. It can take months to fix bugs that make the extension unusable when a new MediaWiki version is released.
  • Unmaintained extensions that worked on previous versions of MediaWiki but are broken on recent versions of MediaWiki and there are no volunteers that provide patches for them to work (abandoned).

Those are the 4 status that I think would be useful to know about an extension.

Jeblad (talkcontribs)

I would say the order is

  1. (experimental) Extensions with very active development that expect breaking changes as new features are being added. (start-of-life)
  2. (unstable) Extensions that are out of the most active phase, is usable, but still without a live testing environment. An extension in unstable could have critical issues.
  3. (testing) Extensions that are out of the most active phase, and is usable, with a live testing environment. An extension in testing should not have critical issues. (The template should link to the testing environment.)
  4. (stable) Extensions that are maintained and kept up-to-date with the release lifecycle of MediaWiki, with no expected breaking changes.
  5. (oldstable) Unmaintained extensions that are kept up-to-date by volunteers but there's no official maintainer. It can take months to fix bugs that make the extension unusable when a new MediaWiki version is released.
  6. (abandoned) Unmaintained extensions that worked on previous versions of MediaWiki but are broken on recent versions of MediaWiki and there are no volunteers that provide patches for them to work. (end-of-life)
  7. (archived) After a one year grace period as abandoned the extension should be archived.

We should probably have some kind of badges on the extension page, like there are at Github, to show which extensions passes unit test, and also the number of open issues.

Ciencia Al Poder (talkcontribs)

I don't see how unstable and testing fits with extensions. What do you expect as a "testing environment"? Extensions in such a state can be in a production environment (live wikis not meant to be a testing wiki), and those names have no meaning about usability or critical issues, which is misleading. Unstable and testing shouldn't be considered IMHO.

Jeblad (talkcontribs)

A live testing environment is not the same as a production environment. You might set up a production environment with horribly broken software, nothing stops you. Having a testing environment imply that you have (integration) tests and can prove the extension work properly. That is you don't just include the extension and verify it shows up in Special:Version, you actually run real tests. That means most extensions for Mediawiki will only reach unstable, – not testing, not stable, and not oldstable. At some point such extensions go straight to abandoned.

Jeblad (talkcontribs)

An other way to explain it is a ladder of

  1. (experimental) Still being developed as one or more spikes and optionally stabilize, that is largely missing tests
  2. (unstable) Is predominantly developed as test and development cycles, that is it has at least unit tests
  3. (testing) Has public (live or for download) integration and unit tests with good coverage
  4. (stable) Has some form of release management

If you can't prove it to be working, then you can't claim it to be stable.

(Or as a co-worker told me once: Is a completely broken thing stable in its brokedness? It does not implement its intended functionality.)

Ciencia Al Poder (talkcontribs)

I'm against including the existence of coverage test to claim an extension is any of those statuses. A new property in the extension infobox to tell if the extensions has tests could be good, but not for the status of the extension, because it doesn't mean much.

Jeblad (talkcontribs)

And then we're back to why I believe the current status ladder is wrong; it has no real meaning, it is simply (made up) names.

IBMs old status ladder

  1. (pre-alpha) activities performed during the software project before formal testing (Wikibase while being modelled was here.)
  2. (alpha) first phase to begin software testing using white-box techniques
  3. (beta) the software is feature complete but likely to contain a number of known or unknown bugs (perpetual betas live here. This is unstable.)
  4. (release candidate) software with potential to be a final product, unless significant bugs emerge
  5. (stable) software released for general use
Ciencia Al Poder (talkcontribs)

That's more meaningful. Still, "release candidate" probably won't be used

Bawolff (talkcontribs)

I don't think the debian model fits with extensions very well. Status should more be taken a reflection of the quality of the current master release of the software. Some software might start at the top of the "ladder", others might stay at the bottom with no intention of moving up.

I agree though that its mostly meaningless, as its self-assesed, with no shared common understanding of the definition of the labels

Reply to "Status ladder"

Link generated from table1 parameter is truncated

2
Edward Chernenko (talkcontribs)
Ciencia Al Poder (talkcontribs)
Reply to "Link generated from table1 parameter is truncated"