A base ResourceLoaderModule::getTemplates() exists for subclasses
to override. An implementation is provided for ResourceLoaderFileModule.
For file modules, templates can be specified in the following manner:
'example' => array(
'templates' => array(
'bar' => 'templates/foo.html',
),
'scripts' => 'example.js',
),
The delivery system is template language agnostic, and currently
only supports "compiling" plain HTML templates.
This also adds template support to the following modules as a POC:
* mediawiki.feedback
* mediawiki.action.view.postEdit
* mediawiki.special.upload
Works with $wgResourceLoaderStorageEnabled
Change-Id: Ia0c5c8ec960aa6dff12c9626cee41ae9a3286b76
Not ready for merging, and Roan says that the +2 was
most likely accidental and meant to be a -1.
This reverts commit d146934f94.
Change-Id: I3926c9ae9e3c8026fceb3aeedd3b1f1d9b91667b
Preparation work for templating in core.
RL should allow us to ship HTML / template markup from server to client.
Use in Special:Upload and mediawiki.feedback as a proof of concept.
Separation of concerns etc...
See Also:
Ia63d6b6868f23a773e4a41daa0036d4bf2cd6724
Change-Id: I6ff38c12897e3164969a1090449e626001926c3b
Follows-up 9272bc6c47, 03c503da22, 1e063f6078.
One can't wrap arbitrary JavaScript in an if-statement and have
its inner-body mean exactly the same.
Certain statements are only allowed in the top of a scope (such
as hoisted function declarations). These are not allowed inside
a block. They're fine in both global scope and local function
scope, but not inside an if-block of any scope.
The ECMAScript spec only describes what is an allowed token.
Any unexpected token should result in a SyntaxError.
Chrome's implementation (V8) allows function declarations in
blocks and hoists them to *outside* the condition. Firefox's
SpiderMonkey silently ignores the statement. Neither throw a
SyntaxError.
Rgular ResourceLoader responses only contain mw.loader.implement()
and mw.loader.state() call which could be wrapped without issues.
However such responses don't need wrapping as they're only made
by mediawiki.js (in which case mw is obviously loaded). The
wrapping is for legacy scripts that execute in the global scope.
For those, let's wrap the script tag itself (instead of the
response). That seems like the most water-tight and semantically
correct solution.
Had to bring in $isRaw from ResourceLoader.php, else the startup
module would have been wrapped as well (added regression test).
Bug: 69924
Change-Id: Iedda0464f734ba5f7a884726487f6c7e07d444f1
Follows-up 9272bc6c47, 03c503da22.
* In 9272bc6c47, the condition wrap was removed from
OutputPage for no reason. This went unnnoticed as I had also
accidentally made the cond wrap in makeModuleResponse apply
to both only=scripts and regular (faux) responses, such as by
OutputPage embedding private modules.
* In 03c503da22, the latter bug was fixed, thus exposing the former.
This wrapper belongs in OutputPage, not in ResourceLoader. It's
OutputPage making the loader request. And just like in other places,
it's the "client"'s responsibility to ensure the request is either not
made or wrapped appropriately.
The test for "private module (only=scripts)" could be removed but
I'll keep it so we can see how this changes in the future. It's
a case that can't ever happen, but if it would, it currently gets
a double condition wrapper, which is fine.
Change-Id: Id333e4958ed769831fabca02164c1e8505962d57
Follows-up 9272bc6c47. The shouldIncludeScripts method returns
true for only=scripts, but also for other responses (except for
only=styles, naturally).
Regular load.php responses that load both scripts and styles don't
need the conditional wrap because those requests should only be
made from the mw.loader client which inherently means the
environment has been provided already.
It's merely unnecessary and shouldn't have caused any issues since
it simply evaluates to true always. It was already correctly being
excluded from raw modules that run before the environment is
provided (such as startup, jquery and mediawiki).
Change-Id: I375a7a8039f9b3ad4909e76005725f7d975d8a5e
We currently have a few legacy requests to the load.php end point
that bypass the ResourceLoader client by coding a request to
load.php via a "<script src>" directly. Most prominently the
request for the 'site' wiki module (aka MediaWiki:Common.js).
Remove the manual wrapping of embedded private modules as this
is now taken are of by ResourceLoader::makeModuleResponse itself.
Misc:
* Mark "jquery" and "mediawiki" as Raw modules. While the startup
module had this already, these didn't. Without this, they'd
get the conditional wrap – which would be a problem since mediawiki.js
can't be conditional on 'window.mw' for that file defines that
namespace itself.
* Strip the cache-key comment in the unit tests because the hash
no longer matches and using the generic 'wiki' dbname was breaking
DB queries.
* Relates to bug 63587.
* See also 05d0f6fefd which expands the reach of the non-JS
environment to IE6 and helped expose this bug.
Change-Id: Icf6ede09b51ce212aa70ff6be4b341762ec75b4d
- Swap "$variable type" to "type $variable"
- Fixed spacing inside docs
- Makes beginning of @param/@var/@throws in capital
- Changed some types to match the more common spelling
Change-Id: Ia041964250d8b7c0349d79dc9b131c5b8696e795
Modeled similar to ConfigFactory, this lets skins
register themselves via a callback, allowing for
proper dependency injection.
Loading via $wgValidSkinNames is still supported,
but considered "legacy", not deprecated though.
Skin::newFromKey is now deprecated (and had only
one caller in an extension, which I'll update
afterwards).
Change-Id: I1960483f87c2ef55c994545239b728fa376f17f4
Removing the hack added in Ib4bdda5e.
This will cause an error message to be shown to almost every MediaWiki
user who upgrades their installation (including us developers) until
they add entries for their skins to LocalSettings. This is deemed an
acceptable trade-off, and the message makes it easy to resolve the
issue.
Bug: 68402
Change-Id: I2596ef73088ce94d78ce3dc3ae4da9d81023a2cb
Whenever Vector is removed from core, this can be replaced with
"fallback" (or something that is shipped with core). Ideally this
test wouldn't depend upon Skin, but that's a whole different issue.
Change-Id: I76a74deb95643e0d05f4d0f7e3e8d78f0efc119c
- Added/removed spaces around parenthesis
- Added space after switch/if/foreach
- changed else if to elseif
Change-Id: I99cda543e0e077320091addd75c188cb6e3a42c2
This does not fix all problems (the "combined" test still fails
horribly on my machine for a reason I don't understand). However,
this patch fixes at least two of the problems:
Make the test independent from the wgResourceLoaderDebug setting.
Make the test independent from the wgLanguageCode setting.
Change-Id: I3aa52fed530d852b34b6058e29620749e11092a0
It only really made sense in pair with $wgHandheldStyle, and that has
been removed in Ia8d79b4a.
Remove irrelevant tests, adjust still relevant ones.
Change-Id: I7c24128f7b148d0244538ad95bb60bf09ec4b5cb
