At 2/28/2005 04:59 AM, Brion Vibber wrote:
Sebastien BARRE wrote: [snip]
Note that this code is slightly identical to Title::invalidateCache.
[snip]
That way, cur_touched is always fresher than the cache, and the page always gets re-created. Am I missing something ?
While this might happen to work, it's not really a very good solution; the technique is very oblique (which would make it hard to maintain), and it'll produce a lot of unnecessary writes to the database.
Oh I agree, it's definitely a hack, and is not intended for a large web site, but as much as I like MediaWiki, it was the only quick workaround I could find to go around what I consider a (small) design flaw: to my opinion, the current extension feature is rendered pretty much useless by the current caching mechanism.
Instead, you should try adding a "don't cache this page" flag to the parser, which an extension could trigger.
There is such thing I assume, the invalidateCache() method is close enough, am I right ? But there is no way to call it early enough. What might (also) be missing, I think, is more hooks so that extensions can have a chance to trigger code at earlier stage in the parsing process. Actually as far as I'm concerned, a safe assumption would require less work: if an extension tag is detected in a page, it should always be re-created (unless some global flags is set, if you really want to disable that on large project like Wikipedia).
-- Sebastien Barre