The code previously here did not work well as it merely forwarded the
hash from the current web request. This had numerous issues:
1. It was often null because requests for stylesheets do not cary
a version hash.
2. When requested by JavaScript, the version hash would be a
combination-hash of many unrelated modules, thus when requested as
part of different batches, it would produce different urls which
is not ideal.
The impact of this is minimal currently because we basically never use
these urls, as SVGs are almost always embedded instead of ref'ed by url.
PNG urls are only generated for non-JS modules and then only used in older
browsers not supporting SVG. And, even after all that, for the edge case
of an SVG being ref'ed by url, they would be stored in LocalStorage by
mw.loader with the name+version of the module the image belonged to, not
the version hash of the batch request it came with.
Which means that, yes, localstorage key for "somemodule+someversion" would
have different values for different users, based on which batch the value
came with, because the image urls were using the version hash of the batch
request from ResourceLoaderContext. This is weird, but didn't cause bugs
or inefficiencies because the user would never be exposed to the other
possible urls for that image because we always check LocalStorage first.
It did cause fragmentation server-side in Varnish, though.
This is all fixed now by always including a version, and setting it to
the version of the module. This means there is no more Varnish fragmentation
for these. And it means that browsers are now allowed to cache the images
served from these urls for 30+ days (immutable) instead of only 5min,
which is what happened when they didn't have a version parameter (or set to
null).
Bug: T233343
Change-Id: I4af7fda03698ed4c288d154e7787fb2f3cbbe6c5
* Add license header where missing.
* Add missing `@since` (1.17 for most classes), except
ResourceLoaderLessVarFileModule since 1.32 (1bc62c548c).
* Remove duplicate file-level description for class-only files,
merge with the class description instead.
* Remove my own `@author` annotation from one file.
* Mark core's own FileModule subclasses as `@internal`, except
for the following which we support use of in extensions:
ResourceLoaderLessVarFileModule,
ResourceLoaderOOUIIconPackModule, and
ResourceLoaderWikiModule.
Change-Id: I336af2e4ccdbe2512594e8861b72628d24194e41
Use SVGReader->getMetadata() directly. Also rename the test,
because it covers the implementation and not the wrapper.
Change-Id: I61565c6aadc6d1c1e942b9bc4555ef4aeb09e5d8
The parameter 'lang' is only added to the URL when the image vary on the
language or on the direction.
Also omit the parameter 'lang' when the value is equal to
ResourceLoaderContext::DEFAULT_LANG.
This change makes the URLs shorter and reduces the size of the
stylesheets.
This change also improves caching because the URLs do not vary on the
language for the same image.
Change-Id: Id7d8ecc7d95747f3c157f9abc12e8489e5085aff
This change follows I39cc2a735d9625c87bf4ede6f5fb0ec441d47dcc.
docs/extension.schema.v1.json
docs/extension.schema.v2.json
includes/registration/ExtensionProcessor.php
* The new extension attribute 'OOUIThemePaths' can be used to define
custom OOUI themes. See I9187a63e509b601b8558ea82850fa828e5c8cc0a
for an example usage.
includes/resourceloader/ResourceLoaderOOUIModule.php
* Add support for 'OOUIThemePaths'.
* Defining 'images' is now optional. I figure custom themes are
unlikely to have or need them.
* Use ResourceLoaderFilePath objects to allow skin-/extension-defined
OOUI module files to use skin/extension's base paths.
This was previously used to support $wgResourceModuleSkinStyles,
but only for 'skinStyles' - now ResourceLoaderFileModule needs
to also handle it for 'skinScripts', and ResourceLoaderImageModule
for 'images').
includes/resourceloader/ResourceLoaderFilePath.php
* Add getters for local/remote base paths, for when we need to
construct a new ResourceLoaderFilePath based on existing one.
includes/resourceloader/ResourceLoaderFileModule.php
includes/resourceloader/ResourceLoaderImageModule.php
includes/resourceloader/ResourceLoaderOOUIImageModule.php
* Add or improve handling of ResourceLoaderFilePaths:
* Replace `(array)` casts with explicit array wrapping, to avoid
casting objects into associative arrays.
* Use getLocalPath() instead of string concatenation.
tests/phpunit/includes/resourceloader/ResourceLoaderFileModuleTest.php
tests/phpunit/includes/resourceloader/ResourceLoaderImageModuleTest.php
* Some basic checks for the above.
Bug: T100896
Change-Id: I74362f0fc215b26f1f104ce7bdbbac1e106736ad
Throw an exception in ResourceLoaderImage::getPath when there is no
matching path instead of continue with null.
Change-Id: I677f4a53f4c90af27db0cc2fd8ef5f028fb49168
We were creating the `<g>` element without specifying a namespace,
which caused the library to add `xmlns` attributes with the document's
default SVG namespace to elements that we appended underneath it.
(At least, that's what I think was happening.)
Specify the SVG namespace when creating it to avoid the mess and
reduce resulting file size.
Change-Id: Ida27494aeae9dece16f878c16cf9aa582e6deac3
While it shouldn't be causing any rendering problems,
doing so is semantically incorrect.
Bug: T213507
Change-Id: Ic86cd2bf3028eb24ad60db7ffa9498dd86edd4a5
In the message store, all messages fall through to English,
but only a few languages should actually explicitly fallback
to English (English variants and dialects).
These new explicit fallbacks are used by ResourceLoaderImageModule,
and this change doesn't affect the message fall through system.
Bug: T203350
Change-Id: I6b68a17f4d69341bccdae748727b5133a600d8bc
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
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
Follows-up b5e69c4ef which did the same for already for ResourceLoader.php.
There's no need to expand the hostname into these urls. If load.php
is on the same domain (e.g. set to '/w/load.php') then this can be
resolved by the browser normally.
If load.php is on a custom domain, the stylesheet would be served
from there instead of from the wiki domain. However in that case
the hostname would already be part of $script value ($wgLoadScript).
Bug: T125292
Change-Id: I7242445335d69d7ae290da5f321a59edd537d819
Some users are reporting that DomDocument::load can't read the files
on their setups, while they can be read with file_get_contents. So use
that and pass the string to DomDocument::loadXml. The advantage of
DomDocument::load is supposed to be in handling large files, and the
icons here are supposed to be small.
Bug: T107198
Change-Id: I8e4dc4642f9d0c5f01ec5e4061e83bf09d0a4900
- Removed space after casts
- Removed spaces in array index
- Added spaces around string concat
- Added space after words: switch, foreach
- else if -> elseif
- Removed parentheses around require_once, because it is not a function
- Added newline at end of file
- Removed double spaces
- Added spaces around operations
- Removed repeated newlines
Bug: T102609
Change-Id: Ib860222b24f8ad8e9062cd4dc42ec88dc63fb49e
array( "en,de,fr" => "foo.svg" ) now means the same as
array( "en" => "foo.svg", "de" => "foo.svg", "fr" => "foo.svg" ).
Bug: T76539
Change-Id: I0bf82e06be3c5f94b6ac88bbc0437b5229ceb284
- Check $wgSVGConverter to see if it starts with rsvg, instead
of just being rsvg. Other things like rsvg-secure are also ok.
- Make sure SvgHandler::rasterize() returned sanely before attempting
to use the file it produces.
- Clean up temp SVG file if we return early
- Add some debug logging when rasterization fails
Bug: T89505
Change-Id: I9483c8c54a30e328565182b00d50dbf3b83076cd
Update $wgSVGConverters['rsvg'] to something closer to WMF production
configuration (there is a more complicated setup involving two
variants of rsvg for some reason).
Documentation is scarce, but 'rsvg-convert' appears to be the "modern"
way to call rsvg, with 'rsvg' being deprecated or not recommended.
Bug: T76476
Change-Id: I5ed877f3a5a1f1e97ae881c1d03fc977276182b6
ResourceLoaderImageModule needs a set of SVG files and some data in
the module definition, and produces styles for a set of CSS classes,
one for each image, optionally with differently colored variants,
generated in SVG and PNG, data-URI-embedded if possible, compatible
with all browsers, and generally slick.
The intended usage is to ship icon libraries with MediaWiki that can
be used throughout the pages with no additional code.
* ResourceLoaderImageModule implements all of the logic for data
parsing and CSS generation.
* ResourceLoaderImage implements the logic for SVG image colorization
(for variants) and rasterization.
* ResourceLoader and ResourceLoaderContext were extended to serve a
new kind of load.php request that delivers a single image file. This
is used for fallback PNG images served to browsers that don't
understand SVG.
See change Ic6a76bfb for a demo.
Bug: T76473
Co-Authored-By: Trevor Parscal <trevorparscal@gmail.com>
Co-Authored-By: Bartosz Dziewoński <matma.rex@gmail.com>
Change-Id: Idf6ff4eb8e94f45946f15d283d34108b881fae6e
