(Your use of my image has summoned me...woooo....👻)

If this doesn't get picked up and you're desperate, a JS script can do this fairly easily with the embeddedin list on the API

@Inductiveload Can you elaborate? embeddedin doesn't seem to accept prefixes. So it has to either get all pages transcluding the template first (which wouldn't work well for editing a template with >5000 transclusions) or query templates prop in generator=prefixsearch (which is inefficient as it returns all pages with the prefix and then checks for those that use the template). Or is there a neater way?

I don't really have a better idea than what you said, it was just a thought that might scratch an itch until this gets done properly.

I see, thanks for the suggestion anyway.

(Nardog subsequently wrote a script for this, it's TemplatePreviewGuard. This really should still just be in core.)

@Izno It's not quite what this task is asking for, though, as it just checks when you click the button. It wouldn't be difficult to implement it since it's just a script, but I also believe the PHP side should just give you an error instead of the unaltered version of the page.

There's no index which would allow efficient autocomplete prefix searches on pages that use a given template. But we could apply a CSS class to items in the menu depending on whether the page uses the template. If the number of pages using the template is small (<200) then there could be a separate mode where we only suggest those pages, although the mode switch might be surprising to users.

There are two implementations of this feature: one for core EditPage and one for VE. Both use TitleInputWidget, which I think will need to be subclassed. Compare MWTemplateTitleInputWidget in VE. We could override getApiParams to add prop=templates, tltemplates=....

Adding a class or icon to the menu option is the responsibility of the TitleOptionWidget constructor. It could either be subclassed as well, or the option could be modified after construction by createOptionWidget.

We could add the color-disabled text colour to the label. We could also sort the list, putting titles that use the template first, by analogy with what is done for disambiguation pages.

onLookupMenuChoose could show a warning message when a title without the template is selected.

Link tables are not necessarily correct or up to date, so I think it should still be possible to submit the form when such a title is selected. However, once the parse is actually done, we have the used templates in the ParserOutput so we can use that to warn the user if the template was not in fact used. In the VE implementation, this information can be obtained by adding templates to the prop parameter in the action=parse request. In the EditPage implementation, we have the ParserOutput object in onAlternateEditPreview and we can use it to modify the HTML.

If the template was not used, we could hide the preview HTML by putting it in a collapsed box. Or we could just not display it at all. Is there any use case for seeing the HTML when the template being edited was not used?

Wishathon project plan

MVP: error only

• In ext.TemplateSandbox.VisualEditor.js
  • Add prop=templates to the parse request
  • Conditionally add an error message if the template was not used
• In onAlternateEditPreview(), conditionally add an error message
• Add suitable CSS and i18n

Stage 2: Autocomplete assistance

• Subclass TitleInputWidget on the client side
  • Override getApiParams, adding prop=templates and tltemplates.
  • Override getLookupMenuOptionsFromData, receiving template data.
  • Conditionally add a label class to the menu options.
  • In ext.TemplateSandbox.VisualEditor.js use the subclass
• Subclass TitleInputWidget on the server side
  • Override getJavaScriptClassName
  • Override getConfig, providing the template name.
• Add suitable CSS
• Consider showing an error message when a bad option is selected

Stage 3: extension maintenance

• Review workboard MediaWiki-extensions-TemplateSandbox

If the template was not used, we could hide the preview HTML by putting it in a collapsed box. Or we could just not display it at all. Is there any use case for seeing the HTML when the template being edited was not used?

I doubt there is, but tangentially, I use advancedtemplatesandbox.js and manipulate wpTemplateSandboxTemplate. That field may be made visible (and turned into a title widget) while we're at it. (So at any rate please don't restrict it to wgPageName.) See also Talk:Community Wishlist/W265.

Change #1207011 had a related patch set uploaded (by Tim Starling; author: Tim Starling):

[mediawiki/extensions/TemplateSandbox@master] Show an error message if the template was not used during parse

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

Change #1207038 had a related patch set uploaded (by Tim Starling; author: Tim Starling):

[mediawiki/core@master] widgets: Allow TitleWidget subclasses to override page data

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

Change #1207039 had a related patch set uploaded (by Tim Starling; author: Tim Starling):

[mediawiki/extensions/TemplateSandbox@master] Autocomplete styling for pages that don't use the template

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

Change #1207205 had a related patch set uploaded (by Santiago Faci; author: Santiago Faci):

[mediawiki/core@master] Show an error message when a template is not using when showing a preview

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

Change #1207207 had a related patch set uploaded (by Santiago Faci; author: Santiago Faci):

[mediawiki/extensions/TemplateSandbox@master] Check whether the specified page is using the template before showing its preview

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

Change #1207281 had a related patch set uploaded (by Tim Starling; author: Tim Starling):

[mediawiki/core@master] EditPage: Allow live preview response hooks to show errors

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

Change #1207282 had a related patch set uploaded (by Tim Starling; author: Tim Starling):

[mediawiki/extensions/TemplateSandbox@master] Show the template not used error also on live preview

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

Change #1207281 merged by jenkins-bot:

[mediawiki/core@master] EditPage: Allow live preview response hooks to show errors

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

Change #1207038 merged by jenkins-bot:

[mediawiki/core@master] widgets: Allow TitleWidget subclasses to override page data

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

Change #1207011 merged by jenkins-bot:

[mediawiki/extensions/TemplateSandbox@master] Show an error message if the template was not used during parse

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

Change #1207282 merged by jenkins-bot:

[mediawiki/extensions/TemplateSandbox@master] Show the template not used error also on live preview

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

Test wiki created on Patch demo by Tim Starling using patch(es) linked to this task:
https://6ac9ee7e12.catalyst.wmcloud.org/w/

Change #1208138 had a related patch set uploaded (by Tim Starling; author: Tim Starling):

[mediawiki/extensions/TemplateSandbox@master] Fix VE not used error when the title contains spaces

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

Change #1208138 merged by jenkins-bot:

[mediawiki/extensions/TemplateSandbox@master] Fix VE not used error when the title contains spaces

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

Change #1207205 abandoned by Santiago Faci:

[mediawiki/core@master] Show an error message when a template is not using when showing a preview

Reason:

A new patch is already covering this

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

Change #1207207 abandoned by Santiago Faci:

[mediawiki/extensions/TemplateSandbox@master] Check whether the specified page is using the template before showing its preview

Reason:

A new patch is already covering this

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

Change #1207039 merged by jenkins-bot:

[mediawiki/extensions/TemplateSandbox@master] Autocomplete styling for pages that don't use the template

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

This task looks like it might have adjusted the vertical spacing unintentionally; the preview line was more attached to the form below it than the form above it before today's deploy.

Change #1212286 had a related patch set uploaded (by Tim Starling; author: Tim Starling):

[mediawiki/extensions/TemplateSandbox@master] Fix accidentally removed stylesheet

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

In T279736#11414054, @Izno wrote:

This task looks like it might have adjusted the vertical spacing unintentionally; the preview line was more attached to the form below it than the form above it before today's deploy.

Sorry about that, the patch linked above should fix it.

Change #1212286 merged by jenkins-bot:

[mediawiki/extensions/TemplateSandbox@master] Fix accidentally removed stylesheet

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

Change #1212292 had a related patch set uploaded (by Tim Starling; author: Tim Starling):

[mediawiki/extensions/TemplateSandbox@wmf/1.46.0-wmf.4] Fix accidentally removed stylesheet

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

Change #1212292 merged by jenkins-bot:

[mediawiki/extensions/TemplateSandbox@wmf/1.46.0-wmf.4] Fix accidentally removed stylesheet

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

Mentioned in SAL (#wikimedia-operations) [2025-11-28T01:14:19Z] <tstarling@deploy2002> Started scap sync-world: Backport for [[gerrit:1212292|Fix accidentally removed stylesheet (T279736)]]

Mentioned in SAL (#wikimedia-operations) [2025-11-28T01:16:22Z] <tstarling@deploy2002> tstarling: Backport for [[gerrit:1212292|Fix accidentally removed stylesheet (T279736)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2025-11-28T01:23:53Z] <tstarling@deploy2002> Finished scap sync-world: Backport for [[gerrit:1212292|Fix accidentally removed stylesheet (T279736)]] (duration: 09m 33s)

Thanks for working on this! However, it's unfortunate that in LivePreview, the unaltered page is still downloaded and the error is detected only front-end, which partly defeats the point of the wish because we still have to wait for the entire page to be downloaded before we see the error. Couldn't the API be made to return just an error instead of text if templates doesn't include templatesandboxtitle?

In T279736#11427420, @Nardog wrote:

The "accept" part is resolved, but the "suggest" part is not.

The exact thing that you proposed is infeasible and in my opinion inadvisable, since templatelinks is not necessarily complete and so doesn't necessarily represent whether or not a template can be successfully previewed with that page. I am not recommending any further work in this area. I will update the task description to reflect what was done. You can file separate task with any further work if you like.

I will update the task description to reflect what was done. You can file separate task with any further work if you like.

Please don't, I authored the task and I included the suggest part from the beginning.

@Nardog this is pretty disruptive as it breaks the link trail of gerrit, deploy references and release notes. It is perfectly fine for more specific or followup tasks to branch off from this task, but what you did is the opposite of that.
This could even have been done before any work was committed to the ticket but to do it afterwards is really not how we do this generally.

@TheDJ I can see that, but closing a task that's not fully resolved is also disruptive. Feel free to make T411605 the "suggest" task or whatever but please don't close this as resolved, because it's not.

Test wiki on Patch demo by Tim Starling using patch(es) linked to this task was deleted:

https://6ac9ee7e12.catalyst.wmcloud.org/w/