Ref discussion on T42284.
Test plan:
* Create gadget A with a .css file only. (Maybe mark as 'hidden')
* Create gadget B with .js file, and peers=A.
* Verify that enabling B will result in B being loaded as general module,
and A being loaded as page style module.
Change-Id: Ib6207e72c576ff387ecdba685a063bdfbb828199
T87871 formally introduced the concept of a styles module,
which sets mw.loader.state to "ready" when loaded through addModuleStyles().
Previously, addModuleStyles couldn't safely do that because a module may
contain scripts also, in which case mw.loader must still load the (rest)
of the module (causes styles to load twice).
In MediaWiki core or extensions this is easily avoided by calling not
calling both addModules() and addModuleStyles().
For Gadgets we call both as a workaround to allow users to provide styles
(without a FOUC), but also to provide scripts+styles. Since we don't declare
which one is intended (and some gadgets do both), we loaded them both ways.
This will no longer be allowed in the future (see T92459).
The new 'type=styles' Gadget attribute promises to ResourceLoader that a
gadget only contains styles.
Impact:
* [Bug fix] When mw.loader requires a styles module that already loaded,
it will not load again.
* [Feature] It is possible for a general scripts+styles gadget to depend on
a styles gadget. Previously this caused the styles to load twice.
* Specifying type=styles will load the module through addModuleStyles() only.
Use this for modules that contain styles that relate to elements already
on the page (e.g. when customising the skin, layout, or article content).
* Specifying type=general will load the module through addModules() only.
Use this if your module contains both scripts and styles and the styles
only relate to elements created by the script. This means the styles do not
need to be loaded separately through addModuleStyles() and will not apply
to noscript mode.
Effective difference:
* Gadgets with only styles: We assume type=styles.
This fixes the main bug (styles loading twice) and requires no migration!
* Gadgets with only scripts: We assume type=general.
This requires no migration! (And: No more empty stylesheet request)
* Gadgets with scripts (with or without styles): We assume type=general, but
unless type=general was explicitly set we'll still load it both ways so
that the styles apply directly on page load.
If this is not needed, set type=general.
If this is needed, it should become two separate modules. We do not support
a single module having two purposes (1: apply styles to the page,
2: provide scripts+styles). The styles module should be separate.
It can be made hidden, and listed as dependency of the other module.
The latter case is detected on page load and results in a console warning
with a link to T42284.
Bug: T42284
Bug: T92459
Change-Id: Ia3c9ddee243f710022144fc2884434350695699a
Implements:
* Gadget definition content and content handler
* Basic validation for gadget definition content
* GadgetDefinitionNamespace implementation of GadgetRepo
* DataUpdates upon editing/deletion of Gadget definition pages
* EditFilterMerged hook for improved error messages
* 'GadgetsRepoClass' option to switch GadgetRepo implementation used
* Lazy-load the GadgetResourceLoaderModule class so we don't need to
load each individual gadget object unless its needed
Note that Special:Gadgets's export feature intentionally doesn't work
yet, and will be fixed in a follow up patch.
Bug: T106177
Change-Id: Ib11db5fb0f7b46793bfa956cf1367f1dc1059b1c
In the backend, allow:
* Adding dependencies on messages
* Marking gadgets as hidden so they don't show in preferences
These cannot be used by MediaWiki:Gadgets-definition gadgets, but will
be used by Gadgets 2.0 gadgets.
Change-Id: I55e97de9d631ae001ccc0164db172ba9c5689a34
GadgetRepo is an abstract class based off of the implementation in the
RL2 branch.
It is a singleton that provides basic methods to construct and interact
with Gadget objects.
The MediaWikiGadgetsDefinition class is an implementation of GadgetsRepo
that parses the "MediaWiki:Gadgets-definition" page for gadget
definitions.
Tests were left in place to demonstrate that no functional changes have
been made aside from relocation of code. Some tests should be moved to
separate files in the future.
Bug: T106176
Change-Id: I3e802889f6f495783f4dbac65c2a8cefa824a778
* APC will be used if around as a tier 1 cache
* This also makes it easier to have mixed zend/hhvm servers
Bug: T106743
Change-Id: Ie9f234753f78215441474dddc4eadedbd2b76ad7
The current method of setting private properties prevents the Gadget
object from being constructed by another class (like a GadgetRepo).
Instead, lets pass in arguments in an array.
Change-Id: I86853c72dfb323fb3e54be9ecff85973e30fe781
* Bumped the key version due to key wrapping
* Removed isValidList() gived the key versioning
* Follow up ba1311c323 by making APC viable;
previously, definition purges would not work
Bug: T93141
Change-Id: I6da3eede044bf4b840b3f9656a1ae8105941dc6b
Add a configuration option, 'GadgetsCacheType', which may be used to specify
the ObjectCache type to use for gadget definitions.
Change-Id: I1e02f7b6c470c5fffa014c6247c71f43a69420b6
When loading the Gadget list, check against ResourceLoader::isValidModuleName
to avoid MWExceptions being thrown.
This will lower the max length of a gadget name from 248 bytes to
244 since ResourceLoader requires <= 255 bytes, and we add a
"ext.gadget." prefix in front of the name.
Bug: 19410
Change-Id: Ib74c0866bb333885c747d318418e2c8685ae339c
Obviously this should be used sparingly, but it's needed for some
initialization stuff like registering plugins with VisualEditor.
Change-Id: Ifeed524a53601a47b3a945ca0a324bbbead0f1f5
After some investigation I could only find a few unlike
possibilities which eventually could lead to the issues
described in the bug. In the end I decided that it would
be the easiest and probably most robust solution to simply
don't cache in case no gadgets were found, even if the
MediaWiki page exists.
This shouldn't cause any performance issues as we already
don't cache in case no gadgets could be found in all paths
of this function except after trying to parse the gadget
definition.
Bug: 37228
Change-Id: I3092bcb162d032282fbe263c7f14f4d1ce9163ab
The mobile environment differs from the desktop environment so various
gadgets may not work as expected. ResourceLoader deals with this for
normal modules by enforcing a 'targets' property that requires
javascript that wants to run on mobile to specify a mobile target.
This change
* Allow other extensions to disallow legacy gadgets
* Allow specifying module targets in similar way to RL, effectively
creating mobile gadgets
Bug: 44918
Change-Id: I9ee852e33412826608b6039fa01a2b0027b35e7b
Though the hook registration was working fine, the run from
Jenkins was failing.
Jenkins runs like this:
$ php tests/phpunit/phpunit.php extensions/Gadgets
Which bypasses UnitTestsList and uses auto-discovery within the
given directory of "*.Test.php" files.
Renamed to file to match PHPUnit's internal discovery pattern
and updated the onUnitTestsList callback to use this pattern
as well.
Also updated documentation applied recent code conventions in
this area (extend MediaWikiTestCase).
Change-Id: Iaa52a5eafdebf1529dd02fb1bed89d27c298e0d3
Now a gadget generates up to three modules:
* The first is known as meta module which still use its original name to keep B/C. It contains no contents, with dependencies of ones specified by user, scripts module, and styles module. See below.
* The second is known as scripts module whose name ends with ".scripts". It contains all scripts in this gadgets, with dependencies specified by user
* The third is known as styles module whose name ends with ".styles". It contains all styles in this gadgets and loaded before documents. After its load it's instantly marked as ready without dependencies resolved (which is the same as dependencies of .scripts but may not be used at all)
The meta module is loaded as if there's only one module under that name, and it's safe for users to reuse that name. The styles module is loaded and marked as ready in <head>, as described above. Normally the scripts and styles modules shouldn't be used by users.
A possible bug that dependency-only gadgets (ie. no scripts or styles) may not be loaded is fixed.
