In T153367#7137447, @Tranve wrote:

More styles should be added to improve the appearance, and wikipage.content hook should be fired.

A query shows that there are 6 million unique non-automatic edit summaries that use this syntax https://quarry.wmflabs.org/query/54289 and considering normal links are already handled like this, I don't see why templates shouldn't be.

Sounds good, hoping for the best!

@Krinkle How would I work on this if there's no active owner? I would love to work on this as it could solve the same issues that the UseResource extension can, but if there's no one to review my commits what's the point?

From what I can tell the only way to solve this would be to add more fields to existing tables that track if the transclusion is directly caused by wikitext, create a new table that stores "template links" rather than transclusions, or to only store direct transclusions in the templatelinks table. The first two options would require changes to the database.

T19571 could also provide similar functionality.

That mostly works, but there are still issues if it's done that way. Let's say template A redirects to template B. If page 1 transcludes template A and template B, but page 2 just transcludes template A, they will appear the same in the templatelinks table, making it impossible for WhatLinksHere to correctly display links.

The task couldn't be implemented without adding new functions and config options to HTMLForm to avoid potential XSS injections.

One major use case would be the {{Empty section}} and {{Expand section}} templates at the English Wikipedia. The templates would be able to use this magic word in edit links by adding &section={{SECTION}] to the links. This would make it easier for editors to help expand these sections and not have to navigate to them by scrolling through the editor for the entire page. See this section on the Village Post.

In T275402#6849357, @Legoktm wrote:

This seems to solve a long-standing request for the Gadgets extension T63007: Allow specifying when a gadget should load (conditional category, action, or namespace) among others. But I think adding a separate extension for this will just add more technical debt, and we're already in a lot of debt with Gadgets. I think working on finishing Gadgets 2.0 would be a much better use of resources than trying to deploy and maintain a separate extension, if you'd be interested in working on that.

In T275402#6849230, @RhinosF1 wrote:

How does the differ from TemplateStyles?
Is there any plan to deploy this to WMF sites? just seen

I've gone through the prerequisites at https://www.mediawiki.org/wiki/Writing_an_extension_for_deployment and all of the ones that need to be done have been completed.

There are several ways the behaviour of the magic word can be implemented since templates can have sections.

The extension UseResource is now available, it allows for the inclusion of both JavaScript and CSS in the MediaWiki namespace.

In T275131#6841172, @Amorymeltzer wrote:

You can use the name of the checkbox, so document.getElementsByName('mwProtect-cascade')[0]

That being said, this basically happens every time a form gets converted to ooui, and is a real pain for continuity or scripts/gadgets.

In T235424#6820561, @TerraCodes wrote:

Not sure if it's related to ?action=protect or Pending changes, but the pending changes part of https://en.wikipedia.beta.wmflabs.org/wiki/Main_Page?action=protect isn't in OOUI.

That is covered by the child task T236218.

Unlike the block form, the protect form has "infinite" selected by default whereas the block form has "other" selected, meaning the other textbox is immediately visible on the block form but it wouldn't be if the widget was used on the protect form.

The issue is that when "infinite" is selected (or any of the options in the dropdown) the other textbox is hidden, making it harder to set a custom expiry and making it so the input is only half the width of the form.

@Ammarpad I can still reproduce it no problem.

@Jdlrobson Yes I was, but if it's not feasible, then that's okay.

I would expect the header not to be a header like it does if it's followed by a template that returns something (or for the header to be parsed in both cases). It's also worth noting that parsoid doesn't parse the heading in this case.