Page MenuHomePhabricator

changes to included pages don't flush cache for templates not in Template: namespace
Closed, ResolvedPublic

Description

I often use templates which resides in (which are) normal namespace pages; you
can refer to these by using {{:pagename}} , whereas {{pagename}} would refer to
a page Template:pagename . This allows users without Sysop rights to make use of
other normal pages, e.g. for adding navigation bars, without the need to edit a
Template:page .

Problem:
I noticed, that changes on the referred page :pagename (the one which should be
shown on the parant page) are not rendered - even after a full browser refresh,
which makes me think., that a mediawiki cache problem exists here.

Example in meta.wiki:

Content of parent page http://meta.wikipedia.org/Sandbox/Variablesubstitutionfails:

{{:Sandbox/Variablesubstitutionfails1}}
text body

Now change this http://meta.wikipedia.org/Sandbox/Variablesubstitutionfails1 and
realize, that the change will not be reflected while the wiki renders the parent
page. However, if you actually EDIT (or SHOW EDIT) the parent page, you will see
the changes in the Variablesubstitutionfails1 page.


Version: 1.4.x
Severity: normal
URL: http://meta.wikipedia.org/Sandbox/Variablesubstitutionfails

Details

Reference
bz734

Event Timeline

bzimport raised the priority of this task from to High.Nov 21 2014, 7:01 PM
bzimport set Reference to bz734.
bzimport added a subscriber: Unknown Object (MLST).

wmahan_04 wrote:

What's supposed to happen is this: when a page includes a template,
a link from the page to the template is added to the links table.
Thus when the template is changed, the including article should be
touched to invalidate all cached copies.

However, Article.php only does this invalidation for pages in the
template namespace.

(In reply to comment #1)

What's supposed to happen is this: when a page includes a template,
a link from the page to the template is added to the links table.
Thus when the template is changed, the including article should be
touched to invalidate all cached copies.

However, Article.php only does this invalidation for pages in the
template namespace.

Wil,

at the moment, I am unexperienced with the whole cache concept but understand
what you mean.

Could you find or tell me what exactly to patch, so that every dependent page is
"touched" if an arbitrary page changes, which another one depends of ?

wmahan_04 wrote:

(In reply to comment #2)

at the moment, I am unexperienced with the whole cache concept but understand
what you mean.

Could you find or tell me what exactly to patch, so that every dependent page is
"touched" if an arbitrary page changes, which another one depends of ?

I'm referring to this code in Article.php (both in 1.3 and HEAD):

  1. Template namespace
  2. Purge all articles linking here

if ( $this->mTitle->getNamespace() == NS_TEMPLATE) {

$titles = $this->mTitle->getLinksTo();
Title::touchArray( $titles );

...

Not doing the check for NS_TEMPLATE would fix this problem, but
it's not a good general solution because it would be bad for
performance.

A better long-term solution might be to use a separate table
to represent template inclusions, rather than using the
links table for this purpose

rowan.collins wrote:

[attempt at better summary]

I agree that {trans|in}clusions should be stored in a 'templatelinks' table, not
the general 'links' one; this would not only allow cache purging to be done for
pages with inclusions in *any* namespace, but it would mean we could have a
Special:Whattranscludesthis for templates, distinct from Special:Whatlinkshere.
It would also make other template issues easier to deal with, like the
template-within-a-template caching issue, bug 734, and maybe even bug 572.

bugzillas+padREMOVETHISdu wrote:

What is the "template-within-a-template caching issue" bug no.? If that bug is
not filed yet, IMHO that should be filed. (Couldn't locate the bug through
mediazilla search.)

rowan.collins wrote:

(In reply to comment #5)

What is the "template-within-a-template caching issue" bug no.?

I couldn't find an entry for it either, so I've filed it as bug 983.

rowan.collins wrote:

*** Bug 572 has been marked as a duplicate of this bug. ***

This ought to have been fixed in 1.6 with the new templatelinks table.
Can you confirm?

Fixed in CVS for 1.6 release. All templates loaded during wikitext parsing will be registered in
the templatelinks table, so there is no issue with templates included from other templates. This
behaviour might be counterintuitive for Special:Whatlinkshere, that fact can be reported as a
separate issue if anyone cares.