Last modified: 2006-02-25 00:18:02 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 983 - inclusions should be purged "recursively" ("template within a template problem")
inclusions should be purged "recursively" ("template within a template problem")
Product: MediaWiki
Classification: Unclassified
Templates (Other open bugs)
All All
: Normal normal with 3 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: 4440 (view as bug list)
Depends on: 1065
  Show dependency treegraph
Reported: 2004-12-02 23:01 UTC by Rowan Collins [IMSoP]
Modified: 2006-02-25 00:18 UTC (History)
2 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description Rowan Collins [IMSoP] 2004-12-02 23:01:29 UTC
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.
Comment 1 Wikipedia:en:User:Paddu 2004-12-04 15:13:17 UTC
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.
Comment 2 Andrew Bell (en:BesigedB) 2005-01-01 05:01:00 UTC
This also affects Categorys as described, only there isn't an automatic way of
clearing the cache of a category.
Comment 3 bdk 2006-01-01 11:21:09 UTC
*** Bug 4440 has been marked as a duplicate of this bug. ***
Comment 4 Tim Starling 2006-02-25 00:18:02 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.