Note: calling msg() with no parameter was never supported,
doing this on a RequestContext for example would result in:
PHP Warning: Missing argument 1 for wfMessage() ...followed
by a bunch of fallout.
So this patch only formally declares what was already a
requirement in reality.
Change-Id: I1864afb8bcc641698689828914949a06506d8f3a
In c8ad83310f, 'oojs-ui-core.styles'
was changed to use ResourceLoaderOOUIFileModule instead of plain
ResourceLoaderFileModule. This had the unintended consequence that
ResourceLoader::isFileModule() no longer returned true for it, and
this $wgResourceModuleSkinStyles no longer worked, breaking styling
in Vector.
Additionally, the new ResourceLoaderOOUIFileModule did not respect
the skinScripts/skinStyles options passed in the module definition
(therefore also those from $wgResourceModuleSkinStyles). Merging
them turns out to be a major pain, but it can be done.
Bug: T167042
Change-Id: I7547bbe996467745c1f0b168b40f27eb95c6238d
includes/resourceloader/ResourceLoaderOOUIModule.php
* New trait centralizing some logic for dealing with OOjs UI themes,
previously duplicated in OutputPage, ResourcesOOUI.php and
ResourceLoaderOOUIImageModule.
* Follow-up change I74362f0fc215b26f1f104ce7bdbbac1e106736ad uses this
as a base to allow skins/extensions to define new OOjs UI themes.
resources/Resources.php
resources/ResourcesOOUI.php
includes/resourceloader/ResourceLoader.php
* OOjs UI resource module definitions are moved back to their rightly
place in Resources.php. They are again (almost) normal and static.
* Theme-specific logic is now handled by the module code, definitions
only specify 'themeScripts'/'themeStyles'/'themeImages'.
* ResourcesOOUI.php is deleted and no longer loaded by ResourceLoader.
includes/resourceloader/ResourceLoaderOOUIFileModule.php
includes/resourceloader/ResourceLoaderOOUIImageModule.php
* Glue code previously existing in ResourcesOOUI.php now lives here.
* Use the ResourceLoaderOOUIModule trait to avoid code duplication.
Change-Id: I39cc2a735d9625c87bf4ede6f5fb0ec441d47dcc
This should work the same way as registering API modules via a factory callback.
Point in case: Ifb8611473a971 could avoid global state using this mechanism.
Change-Id: Ifbf29006141ce2a2dff42efa352f406502a06bc6
* Add fileName to cache key to fix T52919. The cached parsed error
message contains the filename, this should be part of the cache
key as otherwise two identical user scripts may report the same
error message, including " on line X of page Y" where Y is whichever
of the two pages first created the cache entry.
* Make the cache key global instead of per-wiki. There is no need
for this to be per-wiki.
Bug: T52919
Change-Id: I6c2718c53be7f6384a6486a4a8718ae7f423d216
* Simplify by using early return and getWithSetCallback.
* Add TTL (previously indefinite, now 1 week).
Bug: T52919
Change-Id: Ic95ba392cdb3bcc8081c77d2c2a3240548bed366
Previously it was only in debug logs (which are enabled in Jenkins,
MediaWiki-Vagrant, Beta, and for mwdebug hosts in wmf-production).
Turning it into a warning() will log it for regular requests as well
which is the last step before we can consider hard enforcement.
Bug: T92459
Change-Id: I87c7794c5cfe35521bf76cc42f94907001e9d24b
Follows-up 5f55e9c9c2.
If the logo url is from within /w, then ResourceLoaderSkinModule
will (as it should) apply a file hash query to it.
The preloader didn't do that, so it specified the wrong url.
Refactored SkinModule to make this logic re-usable.
Bug: T100999
Change-Id: I1ba11f7c70d1a725ad72754fee4a3f33c2a4c1be
This greatly increases the priority of loading
the logo on browsers that support rel="preload".
Bug: T100999
Change-Id: I0738fcc0a575153dab65016fa87faaa9b8b97a9d
Follows-up 0ac4f998 (restore "blocking" legacy modules).
After d790562, legacy modules in the top queue were no longer consistently
loaded before the bottom queue due to the top queue being async.
The implied dependency was made explicit by 0ac4f998 by forcing all modules
to wait for legacy modules before executing.
This had the negative side-effect of putting an extra HTTP request between
the startup module request, base modules request, and actual execution
of page modules.
(Indentation aligns with when a request is triggered.)
Before:
1. Request: Startup module.
2. Request: Base modules
3. Request: Legacy modules
4. Page module request (or local store hit) and execution
After:
1. Request: Startup module.
2. Request: Base+legacy modules
3. Page module request (or local store hit) and execution
This could alternatively be fixed by moving the top queue to be before
the embedded modules and enforcing the embed in a different way.
It could also be fixed by debouncing module load calls so they naturally
end up in the same request as page modules.
However for now I'm addressing this by adding legacy modules to the
list of modules in the initial load request from the startup module.
This was not possible before because the legacy wikibits had dependencies
and base modules cannot have dependencies. Fixed in I7f9f61ea81ad1ef.
Bug: T159911
Change-Id: I54f087655e1cde1b8ff1ca5fe56e82f7f7d80965
preloadTitleInfo:
* Add missing case for empty $moduleNames.
* Add missing case for invalid page names.
getContent:
* Add missing case for bad title
* Add missing case for dead redirect.
* Add missing case for no content found.
Change-Id: I44dde13cb0db19d91c4ff15a5abefd17353cad90
It turns out that 'resources/lib/oojs-ui/themes/mediawiki/Moved since v0.20.1, use from the 'interactions' pack instead.'
is not usually an existing file, and doesn't have the extension '.svg'.
Not sure why this didn't break earlier.
Bonus: Add module name to exceptions to make these errors easier
to track down.
Bonus #2: Use the post-expansion, not pre-expansion, definition everywhere
to avoid confusion when debugging.
Change-Id: I0325d4dab5658fd29c3c33fd3e762834b53d1b5d
Use getDefinitionSummary instead, which uses a single serialisation
pass instead of requiring every stage to be a string. This way
we don't need to call json_encode and md5() multiple times.
getModifiedHash() was deprecated in MediaWiki 1.26.
Change-Id: If9e9caa3d12976c99543ad53ab280355b70acb17
Some used a string value, others an array with 'message' property.
Standardise on the string value, which seems more intuitive.
Change-Id: I5caead7b7017d2bad660db02fb45a54a26bf3728
Previously, in skins using non-default OOUI theme (for example,
in MonoBook skin which uses Apex theme), when using a browser that
we don't serve SVG images to (for example, Internet Explorer 8),
the user would see the default theme's icons. This is noticeable
e.g. with the search box's icon on Special:Search.
Change-Id: I5a563c59efb267d8080161271513c0cc7d90d610
Values in SkinOOUIThemes are TitleCase, but these filenames are
lowercase. And we silently ignore missing files. This only worked for
the default theme, which is hardcoded to lowercase 'mediawiki' above.
Change-Id: I5b14d65a8f7d5219acfa2a40eabbb13617833b26
When the SVG is too big to be embeded it is now included via URL.
Previously it would produce an empty/broken 'url()' value.
Bug: T160532
Change-Id: I158781f9430cfa35737397ac7537a471634c4480
Install the backtrace collector very early, so that we can get the
backtrace even if headers were sent from LocalSettings.php.
Bug: T157392
Change-Id: I9bc732b34481c95afb5362e135a87bd4302498e2
Follows-up 047b60b96d (ref T111481).
The if-condition compared the expanded paths, not the relative paths.
This meant there were two conditions under which the code will perform
a useless write that inserts *literally* the exact same JSON value.
1. The base directory ($IP) changes after a branch upgrade.
2. Paths contain '../', '//' or other unnormalized paths.
The latter caused various Echo and ULS methods to keep writing the
same value because one of their images is referenced in CSS using
'../'. When inserted in the database as relative path and then
expanded again at run-time and compared to the input value, they
don't match ("$IP/foo/../bar.png" != "$IP/bar.png") and cause a write.
Bug: T158813
Change-Id: I223c232d3a8c4337d09ecf7ec6e5cd7cf7effbff
Currently it was still going through fetchTitleInfo() with an empty array on
the majority of requests without wiki modules, e.g. load.php?modules=jquery.
Bug: T158813
Change-Id: Ie33a2b4da572bb30b2e7a69db07790724ec2f03f
It's unreasonable to expect newbies to know that "bug 12345" means "Task T14345"
except where it doesn't, so let's just standardise on the real numbers.
Change-Id: I6f59febaf8fc96e80f8cfc11f4356283f461142a
Previously, style modules were only in a predictable order for production mode.
In debug mode, the order was determined by order in which modules were added
to queue at run time. This made it sometimes hard to debug, especially when
dealing with gadgets that apply in a different order among each other.
Change-Id: I4bff0c91d127e4ad8015cd8c1775220fe460cbc3
Follows-up 1d15085bb3.
The column has a unique index for module name and skin/language pair.
Previously the write lock was on module name, which meant that
shortly after deployment, the following happens:
* Files change on disk.
* (1-5min pass)
* First startup module request after 5min http-cache expires. Detects
one or more changes and updates the version hash of that module.
* Web client subsequently requests this module (if used on that page).
The first time that request comes in, it's a varnish cache miss
and will make RL load all files from disk related to that module
and update the cache index in the module_deps table. At this point
most popular skin/lang pairs fail, except one. As a result, the
other rows remain stale.
* (7-30 days varnish expiry pass OR another change to the module deploys)
* Web client requests this module and tries to update its skin/lang pair
for that module.
One simple change in January 2016 changes jquery.tablesorter to load
a PNG file instead of a GIF file. Now, over a year later, there are
still a dozen skin/lang pairs in enwiki.module_deps with stale data,
which is causing various suble bugs, as well as filesystem calls for
files that don't exist.
Ref T113916 (refactor module_deps).
Ref T158105 (stale cache bug).
Bug: T158105
Change-Id: Ib6c024bfa8d35ce2d622ba4242291daedb507d5e
This should perform better and reduce internal lock contention on the
database server.
Bug: T158105
Change-Id: I1acfb0630946283b317cb929e8d7c3b2af757ecf
Use of &$this doesn't work in PHP 7.1. For callbacks to methods like
array_map() it's completely unnecessary, while for hooks we still need
to pass a reference and so we need to copy $this into a local variable.
Bug: T153505
Change-Id: I8bbb26e248cd6f213fd0e7460d6d6935a3f9e468
Make ResourceLoader error formatting the same as everywhere else.
Which means if wgShowExceptionDetails is enabled locally, the
trace will be included as well.
This matches logic in MWExceptionRenderer.
Also move the typical error handling used by respond() to a
utility method to reduce duplication of code and avoid mistakes.
Change-Id: If04ae99618e4a758ed0f9dd2b555496b76da29de
