On a local mediawiki installation I extended the SkinTemplateContentActions to add a new Tab to the menu that adds/removes pages from a watchlist-esque table.
Unfortunately, the list of content actions seems to get cached on the page, requiring an action=purge to correctly toggle the contents of the tabs.
I can get around this by calling $this->mTitle->invalidateCache() but I can't see what it is that makes watch/unwatch (or protect/unprotect) not hit the same problem, so I'm not sure whether that's really the right way to do this.
Any pointers would be appreciated.
Thanks,
Tony
Tony Bowden wrote:
Unfortunately, the list of content actions seems to get cached on the page, requiring an action=purge to correctly toggle the contents of the tabs.
I can get around this by calling $this->mTitle->invalidateCache() but I can't see what it is that makes watch/unwatch (or protect/unprotect) not hit the same problem, so I'm not sure whether that's really the right way to do this.
Watch/unwatch updates the user's cache timestamp.
Protect/unprotect updates the page's cache timestamp.
-- brion vibber (brion @ pobox.com)
On Wed, Feb 08, 2006 at 04:03:19PM -0800, Brion Vibber wrote:
Unfortunately, the list of content actions seems to get cached on the page, requiring an action=purge to correctly toggle the contents of the tabs.
Watch/unwatch updates the user's cache timestamp. Protect/unprotect updates the page's cache timestamp.
Ah. This is back up a level - in User::removeWatch, rather than in WatchedItem::removeWatch.
Thanks for the pointer.
I understand that protect will change the page's cache timestamp as the protection is a simple flag on the page, but I'm slightly confused by the watch/unwatch updating the user's cache timestamp, as this information isn't stored directly with the user data, and calling loadFromDatabase doesn't seem to re-load anything to do with the watchlist...
I'm sure I'm missing something really obvious, but I can't quite get my head around the all the caching yet.
Thanks,
Tony
Tony Bowden wrote:
I understand that protect will change the page's cache timestamp as the protection is a simple flag on the page, but I'm slightly confused by the watch/unwatch updating the user's cache timestamp, as this information isn't stored directly with the user data, and calling loadFromDatabase doesn't seem to re-load anything to do with the watchlist...
When something specific to a user changes how pages will display to him/her, the user_touched timestamp is updated so pages cached by the browser from before the change will be rerendered with the new settings.
A change of a page's watched state causes that page to display differently for that user (but not for anyone else), so the user's cache-invalidation timestamp is updated, not the page's.
Quick summary of HTTP caching:
When a resource is sent from the server to a client, it comes with a Last-Modified timestamp, and perhaps some instructions on how the browser should check for validity later. For most page views on the wiki, this instruction tells the browser to go ahead and keep the page cached, but check back with the server every time you visit it.
When you visit the same page again, the browser sends the previous timestamp back as an If-Modified-Since header. MediaWiki compares this timestamp against several cache-invalidation timestamps:
* the sitewide configuration variable $wgCacheEpoch * the page_touched field of the current page * the user_touched field of the viewing user
If the cached time is more recent than all of those, the server returns a '304 Not Modified' code, and the browser displays the page from its cache.
If the cached time is older than any of them, the server sends the whole page again, and the new Last-Modified time is the most recent of all those times.
-- brion vibber (brion @ pobox.com)
On Wed, Feb 08, 2006 at 04:55:51PM -0800, Brion Vibber wrote:
When something specific to a user changes how pages will display to him/her, the user_touched timestamp is updated so pages cached by the browser from before the change will be rerendered with the new settings.
A change of a page's watched state causes that page to display differently for that user (but not for anyone else), so the user's cache-invalidation timestamp is updated, not the page's.
Thanks for the explanation.
Tony
mediawiki-l@lists.wikimedia.org