Page MenuHomePhabricator

TemplateData: Page properties should not be stored twice (both Template and Template/doc)
Closed, ResolvedPublic

Description

This task is about the technical inefficiency of storing it twice in the databases. For the problem of users seeing doc pages as being templates, see T54448: Transclusion dialog should not suggest documentation sub pages as templates.


Consider the following links:

  1. https://en.wikipedia.org/wiki/Special:PagesWithProp/templatedata?limit=100
  2. https://pt.wikipedia.org/wiki/Special:PagesWithProp/templatedata?limit=100

As you can see, the same template data is being stored for both the "Template:Foo/doc" page (or Template:Foo/dados, on ptwiki) and the template itself.

Workaround

Using <includeonly><templatedata>...JSON...</templatedata></includeonly> on "/doc" and "/dados" would solve both the inefficiency and the user problem (T54448), however doing so means the table can no longer be previewed when editing the documentation sub page.

A better approach would be to have a specific namespace, say "JSON:" (take this just as an example) such that "JSON:XYZ" would hold the JSON for "Template:XYZ" (and no other template). So it could be transcluded to "/doc" subpages if the users want that table in the middle of the documentation (which is not always desirable, since it seems a little technical for newbie users, repetitive - because of the template name, its label and its description - and will be too big for templates with a lot of parameters and aliases)

See also:

Details

Reference
bz50512

Related Objects

View Standalone Graph
This task is connected to more than 200 other tasks. Only direct parents and subtasks are shown here. Use View Standalone Graph to show more of the graph.

Event Timeline

bzimport raised the priority of this task from to Normal.Nov 22 2014, 1:57 AM
bzimport added a project: TemplateData.
bzimport set Reference to bz50512.
He7d3r created this task.Jul 1 2013, 6:47 PM

Another solution to the problem of the data being associated both to "Template:Foo" and to "Template:Foo/doc" (although I don't like it as much as a brand new namespace) would be to have an extra parameter which could be used to suppress the data on /docs and only get the table there.

Template:Foo/doc could use something like this:
<templatedata <noinclude>TABLEONLY=YES</noinclude> >...JSON...</templatedata>

or even

<templatedata {{#switch: {{FULLPAGENAME}}

  |Template:Foo|Template:Foo2|...|Template:Foo9
  |#default = TABLEONLY=YES
}} >...JSON...</templatedata>

(when the same /doc is used for more than one template)

Note that it being applied to both /doc and the Template page is not part of the design from TemplateData but part of the way en.wikipedia.org uses it.

Though there are good reasons for it to be that way (I mean, operations actually encourages to use /doc, as otherwise editing the <templatedata> block on Template:Foo will invalidate that template and as such a million articles instead of editing /doc which will only invalidate render cache for Template:Foo itself).

I the spirit of avoiding bugs dictating solutions but instead asking to solve a problem, I'm renaming this bug to reflect the problem so that it can be marked as fixed regardless of how we end up solving it.

(In reply to comment #2)

Note that it being applied to both /doc and the Template page is not part of
the design from TemplateData but part of the way en.wikipedia.org uses it.

I think the "/doc" structure is used in a lot of wikis (at least ptwiki and ptwikibooks uses this model)

Though there are good reasons for it to be that way (I mean, operations
actually encourages to use /doc, as otherwise editing the <templatedata>
block
on Template:Foo will invalidate that template and as such a million articles
instead of editing /doc which will only invalidate render cache for
Template:Foo itself).

Well.. we are having to do the null edits in the templates anyway because of bug 50372

(In reply to comment #4)

(In reply to comment #2)

Though there are good reasons for it to be that way (I mean, operations
actually encourages to use /doc, as otherwise editing the <templatedata>
block > on Template:Foo will invalidate that template and as such a million
articles instead of editing /doc which will only invalidate render cache
for Template:Foo itself).

Well.. we are having to do the null edits in the templates anyway because of
bug 50372

Null edits. Actual content changes (like putting a <templatedata> block in) would cause a full re-render, I believe.

A lot of templates are protected or semi-protected this means there is a practical problem with people adding the templatedata to the actual template.

Null edits are now less of a problem since a change which makes null edits not request recursive page loads and added action=purge&forcerecursivelinkupdate=1 for when you want all transcluding page to be reloaded.

I hit this problem right now and from what I can tell right now VE itself can correctly extract TemplateData from any subpage. However, the script that allows editing the template data does not; I think it would be easier to fix that before moving the data to its own namespace.

He7d3r updated the task description. (Show Details)May 8 2015, 11:34 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJan 15 2016, 9:16 PM
JJMC89 added a subscriber: JJMC89.May 1 2016, 8:26 AM
Krinkle removed a subscriber: Krinkle.May 16 2018, 9:22 PM

I thought this was solved with T125222?

Change 464718 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[mediawiki/extensions/TemplateData@master] Don't store templatedata pageprop on doc-subpage

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

Change 464718 merged by jenkins-bot:
[mediawiki/extensions/TemplateData@master] Don't store templatedata pageprop on doc-subpage

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

(Existing /doc pages will need to be purged, or possibly null-edited, for the documentation metadata to disappear from them.)

Null-edited I *think* to update page_props.