This will make it easier to debug this code and generally to interact
with the registry data before it gets sent out.
Change-Id: I01808ce5d6a0ac6f7a15719bdd2aa90908cb2fbd
- Added spaces after if/foreach/catch
- Added new line before end of file
- Added or removed spaces before/after parenthesis, comma
- Added spaces around string concat
Change-Id: I0590070f1b3542108e242730e8d9a3ba9831e94f
Changes to the static startup.js file are covered by the file
mtime in #getModifiedTime.
Changes to the module registrations are covered by the max
module mtime loop in #getModifiedTime.
But changes to LocalSettings.php etc. affecting mw.config values
embedded in #getScript aren't traceable. Resort to hashing those
and detecting changes between calls that way.
Without this, changes to mw.config never made it live (not even
after the rebuild every 5 minutes) because of 304 Not Modified
being sent between Apache and Varnish. Changes to config either
didn't matter to front-end right away and made it with the next
deployment that changes a different module, or by touching
startup.js to force a version bump.
Simple third party installs were not affected by this bug as their
settings would only be coming from LocalSettings.php (as opposed
to included files) and $wgInvalidateCacheOnLocalSettingsChange is
true by default.
Bug: 28899
Change-Id: I484166923d97368d95beeb40bb209dec9b849033
* Re-ordering code to bring the modifiedTime hack and the
loop it serves closer together.
* Separating the fact that it needs a value and the mtime of
startup.js since that is just one of the three factors we use.
This way it's clearer that the startup.js mtime is not just a
bogus value, but not more or less important than wgCacheEpoch
and modules mtime either.
* Remove duplicate '/* Methods */' comment, we already have this
marker a few methods higher up.
Change-Id: Id3a07f02566c0f04b612b81f8353f70fa4ab3977
Due to the way this function being defined as a function or var
declaration instead of a function expression assigned to a property
it can't be deleted.
JavaScript doesn't throw an error when deletion is not permitted
though, the operator returns false instead.
> delete isCompatible;
false
We already removed 'delete startUp' from mediawiki.js in favour
of startUp = undefined; (r107402, r74325).
Change-Id: I7aa02e3f4deb3a4f00177b70978bfcb83c80988a
Allows for the search interface to be customzied for the particular
search-engine used, and allows collecting client-side performance measurements
that specify which search engine was used.
Change-Id: Ibeda834e9d5dbaf1d7e40c2dacbc60feb2cc4bba
Split the variable assignment and the return statement in two lines for
better readability.
When there was two return statements in one method the logic was swapped
to have only one return statement.
Change-Id: Id7a01b4a2df96036435f9e1a9be5678dd124b0af
Intended to be used in WikiEditor to hide the signature button in content
namespaces. Other uses could be for gadgets or extensions that only need
to work on content pages, or that are internally-facing and should only
be seen on non-content pages.
It is an array of namespace IDs, so that end-users can quickly check
whether wgNamespaceNumber is in this array.
Change-Id: I01d9671dd14aa79e79ed887299c2f5de766f7375
To minimize the number of discrete requests that the browser has to make in
order to render the page, ResourceLoader tries to condense as many modules as
possible into each request. To ensure that the response is not stale,
ResourceLoader tacks the modification time of the most recently modified module
to the request. This behavior makes poor use of locality: an update to a single
module will change the URL that is used to retrieve it and a number of
unrelated modules, causing those modules to be re-retrieved even though they
have not changed since they were last retrieved. This is because the browser
cache is not aware that the response from load.php is a composite of modules
that should be versioned separately.
This patch adds mw.loader.store. On browsers that implement the localStorage
API, the module store serves as a smart complement to the browser cache. Unlike
the browser cache, the module store can slice a concatenated response from
ResourceLoader into its constituent modules and cache each of them separately,
using each module's versioning scheme to determine when the cache should be
invalidated.
Because the localStorage API is synchronous and slower than memory access,
modules are cached as a single JSON blob. At the beginning of the page load
process, the entire blob is loaded from storage into memory. During the load
process, any required modules that are not in the store are fetched from the
server and set in the in-memory store. When the DOM is complete, the store is
synced back to localStorage in a single operation.
* NOTE: The module store is enabled only if $wgResourceLoaderStorageEnabled is
set to true; it is false by default. We can change the default if / when we
establish conclusively that the feature is beneficial and stable.
Change-Id: If2ad2d80db2336fb447817f5c56599667141ec66
If a file type was added to $wgFileExtensions by both local configuration
and defaults in an extension (eg TimedMediaHandler and LocalSettings.php
both adding 'ogg' and 'ogv') it was being listed twice in the UI messages
listing acceptable types.
Runs array_unique() over the array on various outputs.
Bug: 54378
Change-Id: I14cd098d8b27099f8f803630535f33549740295c
The upcoming rewrite of mw.Title needs to use wgLegalTitleChars,
but for that to work, it needs to be converted into something
that can work in javascript.
Signed-off-by: Timo Tijhof <krinklemail@gmail.com>
Signed-off-by: David Chan <david@sheetmusic.org.uk>
Change-Id: I163f3d7e3a680d52640a93f4bd195d8209669918
Also pass a array to wfAppendQuery, which than does the urlencoding.
Prefer a wfScript() over the global or string
Change-Id: Icada534cb4c99c9441938a2e8dcbc11a142360c6
Goes along with MobileFrontend changes: https://gerrit.wikimedia.org/r/28434
Adds 'targets' option to module definitions, defaulting to 'desktop'.
Only a couple more modules are whitelisted into both desktop and mobile for now.
Startup module takes a 'target' parameter (defaults to 'desktop') to filter
the resource module registration list. Only modules matching the filter get
registered, and thus will be loadable from client-side RL.
Change-Id: Ifb772d4995b8e2ec4b63776fe0bb5b0214f82e04
The module has been broken for a while now, but nobody noticed
because in plain core it is disabled by default, and in the
bundle we ship with Extension:Vector (and its SimpleSearch).
This commit removed the mediawiki.legacy.mwsuggest module (and
related components that become obsolete with its deletion) and
replaces it with the new mediawiki.searchSuggest module, which is
based on SimpleSearch from Extension:Vector (where it will be
removed soon).
The following and all references to it in core have been removed,
I also made sure that they weren't used in any of extensions/*.
Only matches in extensions/Settings and some file that dumped the startup module, and in extensions/Vector which are addressed in
I1d5bf81a8a0266c51c99d41eefacc0f4b3ae4b76.
Had to make a few updates to jquery.suggestions to make it work
in other skins. So far it was only used in Vector, but now that
it is used in mediawiki.searchSuggest, I noticed several issues
in other skins. Most importantly the fact that it assumed the
default offset was from the right corner, which isn't the case in
Monobook where the search bar is on the left (in the sidebar).
It now detects the appropiate origin corner automatically, and
also takes directionality of the page into account.
It also uses the correct font-size automatically. Previously it
used font-size: 0.8; but that only works in Vector. Every skin
seems to have its own way of making a sane font-size. In Monobook
the <body> has an extra small font-size which is then fixed in
div#globalWrapper, and in Vector it is extra large, which is then
fixed as well deeper in the document. Either way, the size on
<body> can't be used, and since this suggestions box is appended
to the <body> (it is a generic jQuery plugin without knowledge of
the document, and even if we could give it knowledge inside
the configuration, it'd have to be per-skin). So I removed the
Vector specific font-size and let it handle it automatically.
This was needed because it is now used in all skins.
Removed modules:
* mediawiki.legacy.mwsuggest:
> Replaced with mediawiki.searchSuggest.
Removed messages:
* search-mwsuggest-enabled
* search-mwsuggest-disabled
> No longer used.
Removed mw.config.values:
* wgMWSuggestTemplate
> Obsolete.
* wgSearchNamespaces
> Obsolete.
Removed server-side settings:
* $wgEnableMWSuggest
> Suggestions are now enabled by default and can be disabled
through the user preference `disablesuggest` still.
They can be disabled by default site-wide or hidden from
prefs through the standard mechanisms for that.
* $wgMWSuggestTemplate
> Obsolete.
Removed methods
* SearchEngine::getMWSuggestTemplate()
> Obsolete.
Filters:
$ ack mwsuggest -i -Q --ignore-dir=languages/messages
$ ack wgSearchNamespaces -Q
Message changes:
* vector-simplesearch-preference
> It was wrong, it didn't activate search suggestions, that
was handled by the Vector extension. This preference in
MediaWiki core controls whether the SimpleSearch bar HTML
and CSS will be used (e.g. the rectangle search box with
the magnifying class instead of the browser-default input
field with the plain submit buttons).
* searchsuggest-search
* searchsuggest-containing
These come from Extension:Vector message and should be imported
by translatewiki:
- vector-simplesearch-search
- vector-simplesearch-containing
Change-Id: Icd721011b40bb8d2c20aefa8b359a3e45413a07f
Make javascript variables wgDefaultDateFormat, wgMonthNames and wgMonthNames, used to sort dates in tables, depend on the page content language.
Change-Id: I18a53ba004f3dd877e2d06ed722491167e31b473
This is needed for mobile scripts that are supposed to work on dumb
devices and as such can't rely on client-side RL, but still can take
advantage of server-side minification and concatenation.
Patchset 2: Allow loading raw modules with &raw=true appended to URL.
Change-Id: I9410ffbf6633075e07bd06b10a98a4d12d9b6106
was wrong placed)
And by the way:
* store some result of getters in local variable and use it
* Title::newMainPage always returns an object
* rename a variable
* fix intendation for mw.loader.register call in debug mode
Change-Id: I083b4b61006493602b9345a822a96d538ef89f60
* PHP config variable itself is still needed for sure, but not needed in JavaScript output. Did get into 1.18 (accidentally added to js output as part of r87856) but undocumented and unannounced.
* 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)
* Introduced in r82575 spontaneously, but was never used.
* It was removed from PHP by Tim in r90193, who gracefully kept a work-around in place to still have a protocol available in mw.config.
* Since it was new in JS in 1.18 (which hasn't been released yet), I suggest we take it out right away, especially because the PHP counterpart has been deprecated as well. No release notes needed.
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.
* Based on UploadWizard/resources/mw.Title.js
* Refactored to use local scope and prototypes instead of per-instance private scope (less references, faster instantiation)
* Fix potential ReferenceError in the check for wgArticlePath (inline if statements will fail to evaluate for undeclared variables). Using mw.config instead
* The following were not ported because they are or were already redundant and/or merged with another method:
-- setNameText (redundant with the improved setName)
-- setPrefix (redundant wit the improved setNamespace)
* Ported all jasmine tests to QUnit. Left them exactly the same to make sure it's compatible with UploadWizard. Perhaps I'll expand or adjust the suite later to be less file-specific, but for now make sure it's compatible and the same.
@todo FIXME
* Removed assumption that every title has a namespace prefix in it by creating a separate RegExp when there is a namespace given
** Fixes strip-bug in cases where a namespace appears to be part of a title when the namespace is also given: "Project:User:Foobar"
new mw.Title( 'User:Foobar', 4 ).toString()
> 'Project:Foobar'
** Fixes a thrown exception in case a colon is part of the title (colons are valid in MediaWiki pagenames!)
new mw.Title( 'Just some:Random page')
> Error: mw.Title> Unrecognized canonical namespace: just_some
* Added check for capitalLinks et (wasn't possible before due to bug X)
** Prevents breakages on wiktionary and other wikis with case sensitivity.
Exposing it in the default LocalSettings.php as I did in r90105 was not a good solution, really the only way to avoid breakage is to just get the protocol from $wgServer whenever you need the protocol.
Fixed $wgCookieSecure so that it will be enabled automatically if the user sets $wgServer to an https URL in LocalSettings.php. Added documentation for other cookie-related globals.
Grep indicates that $wgProto is not used by any extensions. $wgCookieSecure is used, hence the need for the Setup.php patch.
Fixes bug in mw.Title constructor when .setNamespace() is used with a canonical namespace on a non-English content-language wiki.
Example: On a German wiki "var foo = new mw.Title('bar').setNamespace('file')" will throw an Error, as wgNamespaceIds only contains localized namespaces + namespace aliases, not canonical ones (in contrary to the assumption that has been made in various places).
(bug 25375) Add canonical namespaces to JavaScript "wgNamespaceIds"
* 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.
