* Added FileCacheBase::*MissesRecent() functions for counting cache misses from different visitors.
* Made ObjectFileCache more generic.
* Cleaned up FileCacheBase::checkCacheDirs().
* Added FileCacheBase::typeSubdirectory() function and overwrote in HTMLFileCache. Fixes r98405 invalidating all existing cache due to directory change.
* Simplified FileCacheBase::checkCacheDirs() a bit
ResourceLoader:
* Use ResourceFileCache to handle load() requests, if $wgUseFileCache. Only caches requests for default language and skins. Single modules requests are always cached, whereas others require a certain threshold of traffic.
* Added ResourceFileCache class (functionality was initially to be in ObjectFileCache).
* ResourceLoader::makeLoaderConditionalScript:
-- window.mediaWiki -> window.mw; Not just because it's shorter but because that's the variable that is actually being used inside the script.
* ProtectionForm::buildCleanupScript
-- Use a single quote string and no new line
-- Use ResourceLoader::makeLoaderConditionalScript instead of duplicating this logic everywhere
* ProtectionForm::buildCleanupScript:
-- Use Xml::encodeJsCall to render javascript code
-- Use ResourceLoader::makeLoaderConditionalScript
-- Fix bug 31230 by using the new OutputPage->addJsConfigVars( r98374 )
(had to use $wgOut for now since there wasn't an obvious route to a context that I could find here (Article has context, but ProtectionForm::__construct takes any WikiPage, not just Article)
* EditPage::getEditToolbar:
-- Use Xml::encodeJsCall
-- Use ResourceLoader::makeLoaderConditionalScript
Fixes:
* (bug 31230) ProtectionForm should set wgCascadeableLevels in mw.confg instead of globally
(I just noticed this while eyeballing the code -- apparently most people don't have multiple output handlers active, given that nobody had caught this in over eight months.)
* Removed the magic behavior where ResourceLoaderModule::getScripts() and getStyles() could return an array of URLs where the documentation said they should return a JS/CSS string. Because I didn't restructure the calling code too much, the old magical behavior should still work.
* Instead, move this behavior to getScriptURLsForDebug() and getStyleURLsForDebug(). The default implementation constructs a single URL for a load.php request for the module with debug=true&only=scripts (or styles). The URL building code duplicates some things from OutputPage::makeResourceLoaderLink(), I'll clean that up later. ResourceLoaderFileModule overrides this method to return URLs to the raw files, using code that I removed from getScripts()/getStyles()
* Add ResourceLoaderModule::supportsURLLoading(), which returns true by default but may return false to indicate that a module does not support loading via a URL. This is needed to respect $this->debugRaw in ResourceLoaderFileModule (set to true for jquery and mediawiki), and obviously for the startup module as well, because we get bootstrapping problems otherwise (can't call mw.loader.implement() when the code for mw.loader isn't loaded yet)
* Make ResourceLoaderUserOptionsModule and ResourceLoaderUserTokensModule depend on mw.user
* Load mw.user.{tokens,options,groups} load as TYPE_COMBINED instead of TYPE_SCRIPT. The latter wouldn't wrap the code in mw.loader.implement()
** ...but make sure 'user' (user scripts) is excluded, that one needs to not be wrapped in a closure
* Make TYPE_COMBINED actually work in makeResourceLoaderLink()
* Add a comment in makeModuleResponse() to explain what the weird is_array( $scripts ) stuff is all about
* Add FIXME about how mw.user.options should split off the CSS part into a separate module
Front-end:
* New mw.loader method: addSource(). Call with two arguments or an object as first argument for multiple registrations
* New property in module registry: "source". Optional for local modules (falls back to 'local'). When loading/using one or more modules, the worker will group the request by source and make separate requests to the sources as needed.
* Re-arranging object properties in mw.loader.register to match the same order all other code parts use.
* Adding documentation for 'source' and where missing updating it to include 'group' as well.
* Refactor of mw.loader.work() by Roan Kattouw and Timo Tijhof:'
-- Additional splitting layer by source (in addition to splitting by group), renamed 'groups' to 'splits'
-- Clean up of the loop, and removing a no longer needed loop after the for-in-loop
-- Much more function documentation in mw.loader.work()
-- Moved caching of wgResourceLoaderMaxQueryLength out of the loop and renamed 'limit' to 'maxQueryLength
Back-end changed provided through patch by Roan Kattouw (to avoid broken code between commits):
* New method in ResourceLoader: addSource(). During construction of ResourceLoader this will be called by default for 'local' with loadScript property set to $wgLoadScript. Additional sources can be registered through $wgResourceLoaderSources (empty array by default)
* Calling mw.loader.addSource from the startup module
* Passing source to mw.loader.register from startup module
* Some new static helper methods
Use:
* By default nothing should change in core, all modules simply default to 'local'. This info originates from the getSource()-method of the ResourceLoaderModule class, which is inherited to all core ResourceLoaderModule-implementations (none override it)
* Third-party users and/or extensions can create new classes extending ResourceLoaderModule, re-implementing the getSource-method to return something else.
Basic example:
$wgResourceLoaderSources['mywiki'] = array( 'loadScript' => 'http://example.org/w/load.php' );
class MyCentralWikiModule extends ResourceLoaderModule {
function getSource(){
return 'mywiki';
}
}
$wgResourceModules['cool.stuff'] => array( 'class' => 'MyCentralWikiModule' );
More complicated example
// imagine some stuff with a ForeignGadgetRepo class, putting stuff in $wgResourceLoaderSources in the __construct() method
class ForeignGadgetRepoGadget extends ResourceLoaderModule {
function getSource(){
return $this->source;
}
}
Loading:
Loading is completely transparent, stuff like $wgOut->addModules() or mw.loader.loader/using both take it as any other module and load from the right source accordingly.
--
This commit is part of the ResourceLoader 2 project.
* Replace the overly paranoid regex with a function that simulates IE6's behavior
* Remove the UA check in isPathInfoBad(), was causing more problems than it was worth
* Revert r87711, going back to using dots for dots in ResourceLoader URLs, instead of exclamation marks
* Append &* to ResourceLoader URLs. * is an illegal character in extensions, and putting it at the end of the URL ensures that both IE6 and our detection function will deem the URL to have no extension (unless something like .html? appears in the query string, but in that case we're screwed no matter what)
* I thought a while for a way to somehow get that global variable from php to the start of the main mediaWiki object creation. Considered using a (temporary) global variable and deleting afterwards, but that looked like a hack and wasn't sure about the cross-browser functioning of it. Instead ended up by moving it to the startUp module where other global variables are accessed as well. This seems to work pretty good.
* Can be toggled from LocalSettings by setting $wgLegacyJavaScriptGlobals.
* Changed some usages of mediaWiki to use the global mw alias instead.
* Expand these URLs in ResourceLoaderContext
* Build and emit these URLs in OutputPage::makeResourceLoaderLink() and in mw.loader
* Throw an exception in ResourceLoader::register() for module names that contain pipe characters or commas. Commas need to be forbidden for this packing feature to work. Pipes were already forbidden but weren't checked for
* Renaming locally declared function "request" to "getScriptTag" to avoid confusion or conflict with the other local "request" function inside the mw.loader closure
* (bug 26804) Code clean up ($skin was generated locally already)
* Also shortens a few wrapper functions the same way
* Partial revert of r82496. Apparantly mw-alias is not available in startUp module. TODO: Find out why ?
(See also r82496 commit message)
TODO: Since the alias is globally available from the start, the 'mw' argument in the wrapper is redundant, so that should be removed at some point as well.
