Last modified: 2014-03-27 20:39:37 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T30899, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 28899 - ResourceLoader: Startup module Last-Modified should take changes to mw.config / LocalSettings into account
ResourceLoader: Startup module Last-Modified should take changes to mw.config...
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
ResourceLoader (Other open bugs)
1.17.x
All All
: Normal major (vote)
: 1.23.0 release
Assigned To: Krinkle
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-05-09 19:33 UTC by Roan Kattouw
Modified: 2014-03-27 20:39 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Roan Kattouw 2011-05-09 19:33:20 UTC
The Last-Modified time of the startup module is the max of the mtimes of all modules, but this doesn't change config changes into account. It should, though. I guess somehow being able to specify a list of config files to check would be best.
Comment 1 Brion Vibber 2011-05-10 18:42:34 UTC
That's traditionally considered to be $wgCacheEpoch's job, but of course because it's applied so widely that might be overmuch.

Maybe make a hash of configuration variables values that affect the startup module?
Comment 2 Roan Kattouw 2011-05-10 18:43:58 UTC
(In reply to comment #1)
> That's traditionally considered to be $wgCacheEpoch's job, but of course
> because it's applied so widely that might be overmuch.
> 
> Maybe make a hash of configuration variables values that affect the startup
> module?
Hmm, that could be a good idea.
Comment 3 Krinkle 2012-06-20 08:30:53 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > That's traditionally considered to be $wgCacheEpoch's job, but of course
> > because it's applied so widely that might be overmuch.
> > 
> > Maybe make a hash of configuration variables values that affect the startup
> > module?
> Hmm, that could be a good idea.

Basically what we're doing in the ResourceLoaderLanguageDataModule (which itself is based on the logic of GlobalDependency)
Comment 4 Krinkle 2013-03-06 04:32:21 UTC
@Roan: All global variables or the ones exposed in mw.config?

It depends on whether we want to invalidate for the mw.config data, or for what could affect things indirectly (e.g. a global configuration variable can affect composition of other modules, or even presence of modules).

Though depending on how the startup module calculates "everything" it might take that into account already in the 5 minute loop.
Comment 5 Krinkle 2013-10-22 18:05:19 UTC
To answer myself:

(In reply to comment #4)
> @Roan: All global variables or the ones exposed in mw.config?

Just the ones exposed.

> Though depending on how the startup module calculates "everything" it might
> take that into account already in the 5 minute loop.

It does.

Let's do this using the new getHashModified approach that landed recently. We'd take a hash of the mw.config object in PHP and possibly any other variables we want to take into account. Similar to how LanguageDataModule cache is invalidated based on values of (unversioned) global variables.
Comment 6 Gerrit Notification Bot 2014-03-20 06:04:56 UTC
Change 119706 had a related patch set uploaded by Krinkle:
ResourceLoaderStartUpModule: Use hashMtime to detect config changes

https://gerrit.wikimedia.org/r/119706
Comment 7 Gerrit Notification Bot 2014-03-26 22:36:48 UTC
Change 119706 merged by jenkins-bot:
ResourceLoaderStartUpModule: Use hashMtime to detect config changes

https://gerrit.wikimedia.org/r/119706

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links