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

Description

Author: rowan.collins

Description:
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) ) {

$next=pop($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

bzimport added a project: MediaWiki-Templates.Via ConduitNov 21 2014, 7:05 PM
bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz983.
bzimport created this task.Via LegacyDec 2 2004, 11:01 PM
bzimport added a comment.Via ConduitDec 4 2004, 3:13 PM

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.

bzimport added a comment.Via ConduitJan 1 2005, 5:01 AM

mozilla-bugzilla wrote:

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

bzimport added a comment.Via ConduitJan 1 2006, 11:21 AM

wiki.bugzilla wrote:

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

tstarling added a comment.Via ConduitFeb 25 2006, 12:18 AM

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.

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.