What exactly is the difference between a cache purge and a null edit (besides the entry in recentchanges)?

On 6/12/05, Zigger zigger@gmail.com wrote:

The "caching problem" is by design, for performance reasons.

With the parser cache on and current, the same value will always be returned, unless "&action=purge" is appended to a query-style URL.

With the parser cache off or expired, as you found, the browser can request a forced refresh e.g. via Ctrl-F5. Alternatively, browser-side caching can be disabled site-wide for all users ($wgCachePages), per logged-in-user (Special:Preferences), or as a user-preference default ($wgDefaultUserOptions['nocache']).

For an example of using an extension to get dynamic content by time-tricking, see http://www.islandseeds.org/wiki/Test:Fortune and http://meta.wikimedia.org/wiki/MediaWiki_FAQ#How_do_I_add_my_own_dynamic_con...

-- Zigger

On 6/11/05, Wolfe, Jeff wrote:

...

... The main page of my wiki has the variable {{NUMBEROFARTICLES}} on it. I'm having a problem with multiple client browsers caching this page and not reloading when the variable changes. If I force a reload, the number is rendered correctly. If I change the wikitext, the page is reloaded. Otherwise, I can press F5 all day and not get the latest copy if only the variable has changed. I have verified this with both IE 6.0 and Firefox 1.0.1. I'm running MediaWiki 1.4.1 with a 'recent changes' patch.

Any ideas? Seems like a caching problem with variables. Can I disable caching for this page only? ...

---

MediaWiki-l mailing list MediaWiki-l@Wikimedia.org http://mail.wikipedia.org/mailman/listinfo/mediawiki-l

On 6/13/05, Jamie Bliss wrote:

What exactly is the difference between a cache purge and a null edit (besides the entry in recentchanges)? ...

There's a few ways to interpret that question. Here's a summary of my limited understanding of how things work for normal MediaWiki pages.

Both the client browser cache and a server parser cache can be purged by the client. The browser knows the modification date of the stored HTML, and can ask the server if the page has changed since then. A parser cache has an expiry time when cached output has to be rendered again. Dummy edits purge/replace the rendered output in the parser cache, and updates the page's modification date. As Rick mentioned, they also re-process templates.

The "time-tricking" example extension simply updates the page's modification date when rendered, which probably works well when there is no parser cache and otherwise has to wait for an expiry or purge in the parser cache before having any effect. It does not force templates to be re-processed.

On the Wikimedia wikis, things are more complex due to the multiple caching-reverse-proxies (squid), slave databases, and an alternative to the table-based parser cache (memcached). MediaWiki can control these somewhat. Other proxies (typically at ISPs) are asked in the headers to basically not cache the pages. Proxies can do all sorts of smart and dumb things to headers.

The caching also has to handle variations in some user preferences, e.g. skin, UI language, date-format.

-- Zigger

Jamie Bliss wrote:

How about I rephrase the question:

Why doesn't purging the cache (via action=purge) rebuild cat links, templates, etc.?

Purging the cache purges the cache. It was added for the explicit purpose of purging the cache, and it doesn't do other things that are not purging the cache.

Would it be useful to be able to do some other things as well? Quite possibly.

-- brion vibber (brion @ pobox.com)