Page MenuHomePhabricator

inclusions should be purged "recursively" ("template within a template problem")
Closed, ResolvedPublic


Author: rowan.collins

If a page ([[A]]) includes a template ("{{B}}"), and that template includes
another template ("{{C}}"), (so the content of [[Template:C]] is visible when
viewing [[A]]), a change to [[Template:C]] will not be visible on [[A]] until
the cache is manually purged. This is because the Template code only purges the
cache for pages which have 'links' entries pointing to [[Template:C]], and [[A]]
is not listed there.

If, as suggested at bug 734, there was a seperate database table for inclusions,
the section of Article.php that handles the purging (in updateArticle()) could
be made to do the purging "recursively". In fact, actual recursion is
unnecessary, we just need 2 lists: "$open" and "$closed"; pseudo-code follows
(omitting boring bits like converting objects to and from strings):

$open = $this->getInclusionsTo();
while(! is_empty($open) ) {

if(isset(($closed[$next])) { continue; } # do each only once
$closed[$next] = true;
array_merge($open, $next->getInclusionsTo());
$pages_to_purge[] = $next; # actually, the array is called "$urls" currently


An alternative solution is to record a link in the database [again, preferably
in an 'inclusionlinks' table] between [[A]] and [[Template:C]] when [[A]]
includes {{B}} and [[Template:B]] includes {{C}}. (I tried to work out what it
is that stops this happening already; but I couldn't understand the code well
enough, and gave up. Is it a deliberate behaviour, or just a product of the way
recursive templates are handled?) This would of course have the side-effect of
[[A]] appearing on a Whatlinkshere-type list of "pages which include
[[Template:C]]", but perhaps this would be a good thing, since, visually, it does.

Version: unspecified
Severity: normal



Event Timeline

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

bugzillas+padREMOVETHISdu wrote:

It looks like separating the "links" table and the "transcludes" table is the
cleanest solution, any other would be a kludge. Mixing the two tables might have
more bugs not yet found, which might require more changes, and soon the code
might become a mess.

Just as we have separate "categorylinks" and "imagelinks" tables (according to
bug 939 comment 3), we should have a "templatelinks" table as well. This allows
{{foo}} and [[Template:foo]] to be treated differently, just like
[[Category:foo]] and [[:Category:foo]] are treated separately, and [[Image:foo]]
and [[:Image:foo]] are treated separately.

Disclaimer: I haven't looked at the code. This is just my intuition.

mozilla-bugzilla wrote:

This also affects Categorys as described, only there isn't an automatic way of
clearing the cache of a category.

wiki.bugzilla wrote:

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

The issue is fixed in CVS for 1.6 release. Recursive purging would be slow, and wouldn't work for
template links created by template arguments, e.g.

a: {{b|some page}}
b: {{ {{{1}}} }}

That's why I chose to register all templates loaded during a parse in the templatelinks table.
This provides good caching behaviour at the expense of perhaps counterintuitive Special:
Whatlinkshere results.