https://bugzilla.wikimedia.org/show_bug.cgi?id=60942
Web browser: --- Bug ID: 60942 Summary: EventLogging modules do not invalidate, since effective mtime is always $wgCacheEpoch Product: MediaWiki extensions Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: Unprioritized Component: EventLogging Assignee: o...@wikimedia.org Reporter: mflasc...@wikimedia.org CC: dtarabore...@wikimedia.org, mflasc...@wikimedia.org, o...@wikimedia.org, sp...@wikimedia.org, swall...@wikimedia.org Classification: Unclassified Mobile Platform: --- Created attachment 14502 --> https://bugzilla.wikimedia.org/attachment.cgi?id=14502&action=edit Script that can be copied into phpsh to see the problem EventLogging modules use the revision as the modified time (except on error, in which case 1 is used). The problem is that ResourceLoaderStartupModule considers $wgCacheEpoch (https://git.wikimedia.org/blob/mediawiki%2Fcore.git/ae03d1a0a38b7aa60a02843ef1e55a680c0166f2/includes%2Fresourceloader%2FResourceLoaderStartUpModule.php#L151). The effective mtime is: max( $moduleMtime, wfTimestamp( TS_UNIX, $wgCacheEpoch ) ); The default $wgCacheEpoch (in DefaultSettings.php) is '20030516000000', which translates to 1053043200, already far greater than the latest revid on Meta. On a real wiki, it will be higher still, since it can be manually set (it is '20130101000000' in production) and on non-production wikis effectively defaults to the mtime of LocalSettings.php. This means changes to the schema never actually update the effective version. I caught this while using the localStorage module storage (even hard-refreshing, which ideally should not be necessary, does not work around this problem). I'm planning to fix it by adding the revid to the UNIX time version of the epoch. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l