Just to clarify, despite being disclosed and announced today, Gadgets is a bundled extension, so the fix was released as part of MediaWiki 1.39.8 / 1.40.4 / 1.41.2 / 1.42.1.

Just mentioning this discussion I opened, wondering if an hidden gadget will surely become loaded for everyone if the "default" keyword is added afterwards, i.e. not at the time the gadget definition was created.

In T204201#9915821, @Od1n wrote:

Would it be difficult to bring compatibility with AJAX previews… if ever it's feasible?

In T63007#9192707, @Krinkle wrote:

In T63007#9192636, @Izno wrote:

[…] but |namespace=-1 also would fit how special pages are dealt with (if that isn't already supported).[…]

namespace=-1 should already work indeed. The reason I suggest also supporting specials as an action is because a number of gadgets enhance the functionality of wikitext textareas, which appear on action=edit in many different namespaces, and on special pages like Special:Upload. action=edit would mean we (correctly) avoid loading the gadget on page views, but also (currently) makes it impossible to load on Special:Upload. namespaces=0,-1 would correctly load both on edit page and upload page, but would also load during page views. From a routing perspective, special pages are the equivalent of action="" or action=null, but to avoid hardcoding that or locking into no other possibilities in the future, I was thinking action=specials could represent that for completion within the Gadgets extension.

So (unless I'm mistaken), basically the rule is "RL may find the category if its wikicode tag exists in the currently displayed content". For instance:

Change #1047718 merged by jenkins-bot:

[integration/config@master] Add Scribunto as a phan dependency for Gadgets extension

https://gerrit.wikimedia.org/r/1047718

This can be done now using the new categories option. The interface messages on top of change list pages (watchlist-summary, recentchanges-summary, recentchangeslinked-summary, histlegend) can be customised to include the category.

Change #1047718 had a related patch set uploaded (by SD0001; author: SD0001):

[integration/config@master] Add Scribunto as a phan dependency for Gadgets extension

https://gerrit.wikimedia.org/r/1047718

Change #1047603 had a related patch set uploaded (by SD0001; author: SD0001):

[mediawiki/extensions/Gadgets@master] Add lua library for retrieving gadgets metadata

https://gerrit.wikimedia.org/r/1047603

In T241524#9873840, @Tgr wrote:

The cache purge probably just requires queueing a links update job with the right parameters; I think that would be the same with a parser function (which would presumably be tracked in the templatelinks table).

In T204201#9877960, @Od1n wrote:

Another issue: I have a case with a gadget ("Diaporama" here) that is defined with a "categories" condition, but this gadget may also be loaded using mw.loader.load()/ mw.loader.using() (by this script), on a page that does not have the category.

In T204201#9877960, @Od1n wrote:

Another issue: I have a case with a gadget ("Diaporama" here) that is defined with a "categories" condition, but this gadget may also be loaded using mw.loader.load()/ mw.loader.using() (by this script), on a page that does not have the category.

In T204201#9873811, @SD0001 wrote:

If you mean during preview, yes it will load if the last saved revision of the page had the category wikicode. What section you're editing is irrelevant.

Another issue: I have a case with a gadget ("Diaporama" here) that is defined with a "categories" condition, but this gadget may also be loaded using mw.loader.load()/ mw.loader.using() (by this script), on a page that does not have the category.

Most of those issues could probably be fixed by using the ContentAlterParserOutput hook instead of BeforePageDisplay, to detect the relevant categories and add the gadgets to the parser output.

I don't think this should be closed just yet. This is still the "more correct" approach. The categories stuff is just a hack to avoid introducing new wikitext.

In T204201#9861245, @Od1n wrote:

About the conditional loading based on categories: If we edit a section (instead of the entire page) and the category wikicode is outside the section, will the gadget be loaded, or not?

The category detection does not work when using quick preview and visual editor.
tested on fr:Moulinet_(échecs), Diaporama gadget is loaded in all cases but these two

Similarly, if the action if a history view, will the page categories be known?

About the conditional loading based on categories: If we edit a section (instead of the entire page) and the category wikicode is outside the section, will the gadget be loaded, or not?

Change #1036653 merged by jenkins-bot:

[mediawiki/extensions/Gadgets@REL1_41] SECURITY: Improve regular expression performance

https://gerrit.wikimedia.org/r/1036653

Change #1036654 merged by jenkins-bot:

[mediawiki/extensions/Gadgets@REL1_40] SECURITY: Improve regular expression performance

https://gerrit.wikimedia.org/r/1036654

Change #1036652 merged by jenkins-bot:

[mediawiki/extensions/Gadgets@REL1_42] SECURITY: Improve regular expression performance

https://gerrit.wikimedia.org/r/1036652

Change #1036655 merged by jenkins-bot:

[mediawiki/extensions/Gadgets@REL1_39] SECURITY: Improve regular expression performance

https://gerrit.wikimedia.org/r/1036655

This should already be possible. The gadget description messages which are used in preferences support full wikitext.

Change #1036655 had a related patch set uploaded (by SBassett; author: SBassett):

[mediawiki/extensions/Gadgets@REL1_39] SECURITY: Improve regular expression performance

https://gerrit.wikimedia.org/r/1036655

Change #1036654 had a related patch set uploaded (by SBassett; author: SBassett):

[mediawiki/extensions/Gadgets@REL1_40] SECURITY: Improve regular expression performance

https://gerrit.wikimedia.org/r/1036654

Change #1036653 had a related patch set uploaded (by SBassett; author: SBassett):

[mediawiki/extensions/Gadgets@REL1_41] SECURITY: Improve regular expression performance

https://gerrit.wikimedia.org/r/1036653

Change #1036652 had a related patch set uploaded (by SBassett; author: SBassett):

[mediawiki/extensions/Gadgets@REL1_42] SECURITY: Improve regular expression performance

https://gerrit.wikimedia.org/r/1036652

Change #1030565 merged by jenkins-bot:

[mediawiki/extensions/Gadgets@master] SECURITY: Improve regular expression performance

https://gerrit.wikimedia.org/r/1030565

In T357197#9833165, @TheDJ wrote:

In T357197#9833164, @Xover wrote:

You can't make that call with a broad brush like "all of MediaWiki" (or rather, you can only do so extremely conservatively), but when we're talking Gadgets we're inherently at a level of granularity where the community not only can, but is actually best situated to make calls like that.

A granularity that however runs inside the same execution pathways of mediawiki, and thus mixes in with all the other code. It is cool you want to do some redecorating, but we are living in the same house. If you poke a hole in the roof, the whole house has a leak, not just your room.

In T357197#9833165, @TheDJ wrote:

Like I get the desire, but you also have to look at the impact of that desire for others.

In T357197#9833164, @Xover wrote:

You can't make that call with a broad brush like "all of MediaWiki" (or rather, you can only do so extremely conservatively), but when we're talking Gadgets we're inherently at a level of granularity where the community not only can, but is actually best situated to make calls like that.

In T357197#9586503, @Nux wrote:

[…]

Big +1 for this I've now hit this issue on two important widely used gadget efforts and have had to resort to creating my own i18n solution or hardcoding strings in a certain language which is not ideal :/

@Majr: Removing task assignee as this open task has been assigned for more than two years - see the email sent to all task assignees on 2024-04-15.
Please assign this task to yourself again if you still realistically [plan to] work on this task - it would be welcome! :)
If this task has been resolved in the meantime, or should not be worked on by anybody ("declined"), please update its task status via "Add Action… 🡒 Change Status".
Also see https://www.mediawiki.org/wiki/Bug_management/Assignee_cleanup for tips how to best manage your individual work in Phabricator. Thanks!

@Jdlrobson: Removing task assignee as this open task has been assigned for more than two years - see the email sent to all task assignees on 2024-04-15.
Please assign this task to yourself again if you still realistically [plan to] work on this task - it would be welcome! :)
If this task has been resolved in the meantime, or should not be worked on by anybody ("declined"), please update its task status via "Add Action… 🡒 Change Status".
Also see https://www.mediawiki.org/wiki/Bug_management/Assignee_cleanup for tips how to best manage your individual work in Phabricator. Thanks!

@SD0001: Removing task assignee as this open task has been assigned for more than two years - see the email sent to all task assignees on 2024-04-15.
Please assign this task to yourself again if you still realistically [plan to] work on this task - it would be welcome! :)
If this task has been resolved in the meantime, or should not be worked on by anybody ("declined"), please update its task status via "Add Action… 🡒 Change Status".
Also see https://www.mediawiki.org/wiki/Bug_management/Assignee_cleanup for tips how to best manage your individual work in Phabricator. Thanks!

Change #1030565 had a related patch set uploaded (by SBassett; author: SBassett):

[mediawiki/extensions/Gadgets@master] SECURITY: Improve regular expression performance

https://gerrit.wikimedia.org/r/1030565