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?
