Change Details

I suspect in practice, it has not been useful or relevant for a contributor on the site to "clear their cache" for any purpose at any time in relation to the MediaWiki software after 2011. But more specifically, not in relation to the kinds of pages where we display this message, which is user- and site script pages. ##### Exhibit A <https://translatewiki.net/wiki/MediaWiki:Clearyourcache/en> Such as rendered above page views on pages like: * <https://en.wikipedia.org/wiki/MediaWiki:Common.css>, <https://www.mediawiki.org/wiki/MediaWiki:Gadget-UTCLiveClock.js> * <https://meta.wikimedia.org/wiki/User:Krinkle/global.js> * <https://meta.wikimedia.org/wiki/MediaWiki:OSM.js> * <https://en.wikipedia.org/wiki/MediaWiki:Citoid-template-type-map.json> ##### Why There are broadly four ways in these site-wide css/js/json pages and personal css/js pages are used: 1. Gadgets and site-wide modules (MediaWiki-namespace Common and skin overrides). These are registered server-side with ResourceLoader and propagated through the [Startup module](https://www.mediawiki.org/wiki/ResourceLoader/Architecture#Caching). The startup module is cached both at our CDN and in the user's browser for ~5 minutes. Besides helping you pass the time, it helps little to nothing to purge your cache or perform a hard refresh. It will progate when it propagates, and when it does, we automatically instruct your brower to perform the relevant HTTP revalidation to renew or replace the entry in your browser cache. 2. User module (User-namespace personal Common and myskin override, including GlobalCssJS). These are registered as the "user" module with ResourceLoader. They are served from a public and cacheable url with a version parameter. Unlike the sidewide modules (which propagate through the startup module after a 5-min delay), the user module propagates immediately through version metadata that we output on all HTML page views for people that are logged-in. The way this works internally is that the metadata of all wiki pages relating to a personal module is stored in Memcached, and post-edit this metadata is purged. If for whatever reason a person gets an older version of their user module, then this is most likely because this update failed for some reason, in which case there isn't much they can do besides wait since the old URL wll specifically relate to the old version and may be CDN-cached outside their browser's control. 3. Directly imported user scripts via action=raw. These work the same way as page views. When a page is edited, we purge the CDN copies for a list of canonical urls such as the desktop/mobile page view URLs, "history" urls, and any relevant action=raw/ctype url. This means that for logged-out people who get content from our CDN receive changes immediately. And for people that are logged-in, these URLs don't have a "blind" cache. (We do allow browsers to cache them, but we require a quick revalidation check on every request to check whether the server has a never version, so there's no real chance of outdated/stale content). 4. Site-wide JSON configuration pages used by the software. Clearing one's cache for these is entirely futile. These are treated as interface messages and cached in the LocalisationCache/MessageCache components, with automatic purging internally. Depending on how the interface message in question is used, it may be behind a few minutes of propagation delay (eg. VisualEditor data module for Citoid configuration), but this is entirely outside the control of the browser.

I suspect in practice, it has not been useful or relevant for a contributor on the site to "clear their cache" for any purpose at any time in relation to the MediaWiki software after 2011. But more specifically, not in relation to the kinds of pages where we display this message, which is user- and site script pages. ##### Exhibit A <https://translatewiki.net/wiki/MediaWiki:Clearyourcache/en> Such as rendered above page views on pages like: * <https://en.wikipedia.org/wiki/MediaWiki:Common.css>, <https://www.mediawiki.org/wiki/MediaWiki:Gadget-UTCLiveClock.js> * <https://meta.wikimedia.org/wiki/User:Krinkle/global.js> * <https://meta.wikimedia.org/wiki/MediaWiki:OSM.js> * <https://en.wikipedia.org/wiki/MediaWiki:Citoid-template-type-map.json> ##### Why There are broadly four ways in these site-wide css/js/json pages and personal css/js pages are used: 1. Gadgets and site-wide modules (MediaWiki-namespace Common and skin overrides). These are registered server-side with ResourceLoader and propagated through the [Startup module](https://www.mediawiki.org/wiki/ResourceLoader/Architecture#Caching). The startup module is cached both at our CDN and in the user's browser for ~5 minutes. Besides helping you pass the time, it helps little to nothing to purge your cache or perform a hard refresh. It will progate when it propagates, and when it does, we automatically instruct your brower to perform the relevant HTTP revalidation to renew or replace the entry in your browser cache. 2. User module (User-namespace personal Common and myskin override, including GlobalCssJS). These are registered as the "user" module with ResourceLoader. They are served from a public and cacheable url with a version parameter. Unlike the sitewide modules (which propagate through the startup module after a 5-min delay), the user module propagates immediately through version metadata that we output on all HTML page views for people that are logged-in. The way this works internally is that the metadata of all wiki pages relating to a personal module is stored in Memcached, and post-edit this metadata is purged. If for whatever reason a person gets an older version of their user module, then this is most likely because this update failed for some reason, in which case there isn't much they can do besides wait since the old URL wll specifically relate to the old version and may be CDN-cached outside their browser's control. 3. Directly imported user scripts via action=raw. These work the same way as page views. When a page is edited, we purge the CDN copies for a list of canonical urls such as the desktop/mobile page view URLs, "history" urls, and any relevant action=raw/ctype url. This means that for logged-out people who get content from our CDN receive changes immediately. And for people that are logged-in, these URLs don't have a "blind" cache. (We do allow browsers to cache them, but we require a quick revalidation check on every request to check whether the server has a never version, so there's no real chance of outdated/stale content). 4. Site-wide JSON configuration pages used by the software. Clearing one's cache for these is entirely futile. These are treated as interface messages and cached in the LocalisationCache/MessageCache components, with automatic purging internally. Depending on how the interface message in question is used, it may be behind a few minutes of propagation delay (eg. VisualEditor data module for Citoid configuration), but this is entirely outside the control of the browser.

I suspect in practice, it has not been useful or relevant for a contributor on the site to "clear their cache" for any purpose at any time in relation to the MediaWiki software after 2011. But more specifically, not in relation to the kinds of pages where we display this message, which is user- and site script pages. ##### Exhibit A <https://translatewiki.net/wiki/MediaWiki:Clearyourcache/en> Such as rendered above page views on pages like: * <https://en.wikipedia.org/wiki/MediaWiki:Common.css>, <https://www.mediawiki.org/wiki/MediaWiki:Gadget-UTCLiveClock.js> * <https://meta.wikimedia.org/wiki/User:Krinkle/global.js> * <https://meta.wikimedia.org/wiki/MediaWiki:OSM.js> * <https://en.wikipedia.org/wiki/MediaWiki:Citoid-template-type-map.json> ##### Why There are broadly four ways in these site-wide css/js/json pages and personal css/js pages are used: 1. Gadgets and site-wide modules (MediaWiki-namespace Common and skin overrides). These are registered server-side with ResourceLoader and propagated through the [Startup module](https://www.mediawiki.org/wiki/ResourceLoader/Architecture#Caching). The startup module is cached both at our CDN and in the user's browser for ~5 minutes. Besides helping you pass the time, it helps little to nothing to purge your cache or perform a hard refresh. It will progate when it propagates, and when it does, we automatically instruct your brower to perform the relevant HTTP revalidation to renew or replace the entry in your browser cache. 2. User module (User-namespace personal Common and myskin override, including GlobalCssJS). These are registered as the "user" module with ResourceLoader. They are served from a public and cacheable url with a version parameter. Unlike the sidtewide modules (which propagate through the startup module after a 5-min delay), the user module propagates immediately through version metadata that we output on all HTML page views for people that are logged-in. The way this works internally is that the metadata of all wiki pages relating to a personal module is stored in Memcached, and post-edit this metadata is purged. If for whatever reason a person gets an older version of their user module, then this is most likely because this update failed for some reason, in which case there isn't much they can do besides wait since the old URL wll specifically relate to the old version and may be CDN-cached outside their browser's control. 3. Directly imported user scripts via action=raw. These work the same way as page views. When a page is edited, we purge the CDN copies for a list of canonical urls such as the desktop/mobile page view URLs, "history" urls, and any relevant action=raw/ctype url. This means that for logged-out people who get content from our CDN receive changes immediately. And for people that are logged-in, these URLs don't have a "blind" cache. (We do allow browsers to cache them, but we require a quick revalidation check on every request to check whether the server has a never version, so there's no real chance of outdated/stale content). 4. Site-wide JSON configuration pages used by the software. Clearing one's cache for these is entirely futile. These are treated as interface messages and cached in the LocalisationCache/MessageCache components, with automatic purging internally. Depending on how the interface message in question is used, it may be behind a few minutes of propagation delay (eg. VisualEditor data module for Citoid configuration), but this is entirely outside the control of the browser.