b> The chances are, this is just caches being a bit slow to clear. A b> normal refresh would probably have caused it all to appear as it b> should.
Indeed, it turns out the problem "went away by itself", without even before me needing to push the purge buttons offered to me. So it is still a problem (race conditions), but one that doesn't last for long.
P.S., Odd that one needs to click to confirm purges: alas this also thus requires a perl LWP script then to accomplish in batch mode.
On 14/12/06, Dan Jacobson jidanni@jidanni.org wrote:
P.S., Odd that one needs to click to confirm purges: alas this also thus requires a perl LWP script then to accomplish in batch mode.
No, it's not odd; it prevents bots, etc. spidering (and thus following) links to purge page caches which are injected into some wiki pages where caches have caused problems in the past. On a large site like Wikipedia, automated purging would cause perpetual invalidation of the cache, and defeat the whole object.
To do a mass purge, one can update the value of $wgCacheEpoch (this would also be accomplished by touching LocalSettings.php where that file was generated by a more recent installer, but I suspect your wiki was established long before that was the case) in LocalSettings.php.
Rob Church
To do a mass purge, one can update the value of $wgCacheEpoch (this would also be accomplished by touching LocalSettings.php where that file was generated by a more recent installer, but I suspect your wiki was established long before that was the case) in LocalSettings.php.
The 1.7.1 LocalSettings.php has # When you make changes to this configuration file, this will make # sure that cached pages are cleared. $configdate = gmdate( 'YmdHis', @filemtime( __FILE__ ) ); $wgCacheEpoch = max( $wgCacheEpoch, $configdate ); so touching it should have been enough it seems.
wikitech-l@lists.wikimedia.org