* 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.
* Uses the new hook in User:getDefaultOptions (bug 30940; r97365)
* This revision is based on a similar one for RL2 in the branch (r97366). Needs to be back ported as the bug occurs in 1.18 as well
TODO:
* Are there instances where we might want to restrict CSS as well as JS?
* Would a $wg config option and/or user preference and/or index.php GET parameter to limit inclusion be useful?
* Can we deprecate any of the existing $wg config options?
* What's going on with the duplicated code between OutputPage and SkinTemplate?
