Our basic support has been updated and Firefox supports replacement
`resolution` since version 8 or 16, depending which data source
one checks.
WebKit's support is a bit more complex and it seems like safest bet is
to leave its vendor prefix in for now.
Bug: T277803
Change-Id: I752f0b67672759824099b4b78892d143344e766f
This reverts commit bc200b6a1a reapplying
the patch. It has been modified slightly to temporarily work
with the beta cluster's unsupported configuration.
Bug: T207038
Change-Id: Ie86a5b59fbf93a400796a4cac3724207830092b5
This reverts commit 33ac451d3d.
Reason for revert: /wiki/Special:Version TypeError: Argument 1 passed to ResourceLoaderSkinModule::getRelativeSizedLogo() must be of the type array, boolean given, called in includes/resourceloader/ResourceLoaderSkinModule.php on line 600
Change-Id: Iddeb33d6165169dc106e9beb3e4a703a4b97eeb6
Gated behind the flag $wgParserEnableLegacyMediaDOM. The scattershot
usage of it is a little unfortunate but isn't expected to live very long
so maybe that's acceptable.
Further details can be found at,
https://www.mediawiki.org/wiki/Parsing/Media_structure
Bug: T51097
Bug: T266148
Bug: T271129
Change-Id: I978187f9f6e9e0a105521ab3e26821e36a96b911
`content` should be mapped to `content-thumbnails` when using list mode
rather than throwing a fatal.
Bug: T271441
Change-Id: Idb30a94803f1432e2c1f57d55eb8c8aef1368dfb
The value of content-media now depends on configuration.
These modules can be merged, as the expectation is both should
apply when the UseNewMediaStructure configuration flag is enabled.
For backwards compatibility map any content-thumbnail requests to
content-media
Bug: T278560
Change-Id: I10ba53b1ee217eae9e05182e989d56f5dc107722
This was added in 381499a675 in response to the issue that when a skin
adopts a feature that was new in MW 1.36, it caused an exception when
that version of the skin is then installed on MW 1.35. That's expected,
and generally helpful because the default support policy requires
like-for-like (MW 1.35 with REL1_35, this applies to all skins and
extensions, except for a few like Translate and SemanticMediaWiki).
However, while supporting LTS within master is unusual, there are
indeed the Translate/SemanticMediaWiki projects, and this problem has
already been solved years ago there by using a conditional with
$wgVersion. The proposed approach on T271441 actually also involves
such a conditional, but late at runtime instead of in the module
definition. Anyway, the way it was fixed in Timeless already solves
the problem by not passing down the invalid feature in the first
place, thus making the 381499a675 patch obsolete. I'm not aware of
any skin in Gerrit having such a compat policy, but if they exist,
they can fix it the same way, by defining the module in code with
a condition, just as Translate/SemanticMediaWiki do.
Bug: T271441
Change-Id: If97b3d04ac1e3355ee4f229db11e524d24ebd27a
* Remove odd use of ResourceLoaderFileModule::extractBasePaths()
SkinModule.php which was basically just returning $IP.
* Use getConfig()->get('ResourceBasePath') so that the test does
not need to override global configuration variables.
Follows-up 6845912bcf and f1457312dc.
Bug: T277728
Change-Id: I64262b48bb5dc71c53b4114eddb2f080a6a076f5
* Remove confusing dead code for T271441, as a continue statement at
the end of a loop body does not do anything. I'll reinstate the
exception once we've looked at whatever skin caused the issue and
have fixed those repos to not pass invalid options.
* Simplify list creation by avoiding the loops and duplicate logic.
Assign the list directly when possible, and otherwise store the
filtered keys.
* Remove unexpected access to `$this->getConfig()` in the constructor.
Follows-up a6c769e976, which worked by accident due to it defaulting
to global state. The injection from ResourceLoader::getModule happens
after the constructor. I am working on a patch to enforce this, and
thus this change needs to land first.
I've moved the logic to getStyleFiles() and boldly changed it to be
a simple skip rather than based on whether it was specified. If this
is a problem we can find a more complex way, but I wanted to try this
first. It seems there is no reason to load these, specified or not,
when the parser feature is not enabled. (Ref T266148)
The unit test was working around this violation in a similar way,
which is now redundant and removed in this patch.
* Document that compatibility method only works on map-form.
* Make applyFeaturesCompatibility() an internal and protected
method. I don't think we'd support extensions calling this
directly.
* Limit applyFeaturesCompatibility() to just dealing with
the features array instead of also handling other options
and applying of the default value.
Bug: T277728
Change-Id: I24a2b783570c888cedee66885647b3ed765e0132
1) Rename content-parser-output to `content-body`
Widen the scope of this module to apply to anything that can be rendered
as the article body. Improve the documentation on what is allowed here.
For early-adopter skins already using content-parser-output,
map the feature to the new name and add tests.
2) Reclaim the `mw-body-content` class for result of
SkinTemplate::wrapHTML
The `mw-body-content` has been used in skins to wrap various elements.
Going forward we will use it to wrap any HTML content generated by
OutputPage.
See dependent patches, which we're not directly depending on to avoid
a CI gremlin:
- I90d85c21f4a62e6697f24e3ce388445a0a53c2b0 (MonoBook)
- I11242e243c9a529b72972089af9ac2a8c906331a (Modern)
- I87942c60e62f6f14acdfeaa1836ace4eac9252ac (CologneBlue)
- I4c1b15d90bacbc9b13782a1d8f52e838ce8ecd83 (Vector)
Bug: T279388
Change-Id: I3a91b294fcb3724cd46743e497dff723de0490a6
It is not entirely meaningless. It might be an indicator that
the number of calls to a method is intentionally unlimited.
This is similar to e.g. an @inheritDoc PHPDoc comment that
marks a method as being "intentionally undocumented".
However, what's the meaning of being "intentionally
unconstrained"? Let's just not have any constraint then.
I feel all these ->expects( $this->any() ) bloat the test
code so much that it's never worth it.
Change-Id: I9925e7706bd03e1666f6eb0b284cb42b0dd3be23
After talking to Volker, the `elements` feature should not contain any
CSS classes. It should apply only on the tag level. I've updated documentation
to explain what's permitted here.
The link styling rules added in b24bff67ed are instead added to a new
feature `content-links`. The existing `content-links` is renamed to
`content-links-external` and for backwards compatibility anyone enabling
`content-links` without `content-links-external` will get the new styles.
The existing legacy feature for backwards compatibility loads the `content-links`
feature which addresses the problem in Timeless with plainlinks styling being lost.
Bug: T279693
Bug: T255717
Bug: T278576
Change-Id: I6e55ed2880782533ea61df98cf16dbf36483d895
Ended up using
grep -Prl '\->setMethods\(' . | xargs sed -r -i 's/setMethods\(/onlyMethods\(/g'
special-casing setMethods( null ) -> onlyMethods( [] )
and then manual fix of failing test (from PS2 onwards).
Bug: T278010
Change-Id: I012dca7ae774bb430c1c44d50991ba0b633353f1
This is a reasonable default for all skins and is small enough
to not be a concern for existing skins.
Also: expand documentation so this is understood better.
Bug: T277218
Change-Id: Ia58037e2c32d76d5c7125772a3243b76ede45f3f
In the case of Monobook, Monobook styles were overriding a
normalize rule and failing to work.
Bug: T269618
Change-Id: Ifa346f60e3a50d874e68043dc4dece3fd8b41aa3
Previously, the order of styles outputted by this module was
arbitrary, based on the order of the feature files passed in.
This was not how it was intended to work - the ResourceLoaderSkinModule
should be aware of the correct ordering.
In the case of normalize for example - it should always be the first
file output.
The implementation is adapted to check for valid features once in
the constructor and to also consider a DEFAULT_FEATURES value has been
set.
We use the FEATURE_FILES constant to determine
the order of CSS output.
This is all documented in the class.
Bug: T269618
Change-Id: Iecbf11b5f09882e55d694651210d6d132d3cd412
Since the legacy parser will also be emitting the new media structure
that requires these styles. For now, the feature is only shipped by
default when $wgUseNewMediaStructure is enabled.
Bug: T51097
Bug: T266148
Change-Id: Id20d716ce145e0bae37621fd6e218a793b5332ae
Follow up to I755e5e6784481b419e35, which used array_unshift
to prepend the 'feature' stylesheets. This works as expected when
there is only one 'feature' enabled.
When there are multiple, use of unshift will effectivel reverse
the order as it unshifts then one at a time.
To mitigate this, collect them normally in the correct order,
and then prepend them all at once with array_merge.
Bug: T262507
Change-Id: Ibe2c9f8d024f6be06588a59df10a37681b60d6bc
For stylesheets provided by features such as normalize or elements,
skins will want to override some styles. Given that ResourceLoader
concatenates all styles, having feature styles override skin provided
styles is counter productive.
Bug: T261080
Change-Id: I755e5e6784481b419e35b338fe3a8129e94b9f61
The name change happened some time ago, and I think its
about time to start using the name name!
(Done with a find and replace)
My personal motivation for doing this is that I have started
trying out vscode as an IDE for mediawiki development, and
right now it doesn't appear to handle php aliases very well
or at all.
Change-Id: I412235d91ae26e4c1c6a62e0dbb7e7cf3c5ed4a6
getAvailableLogos() can now also return multiple items if a 'wordmark'
logo is defined, but this method only cares about the DPI variants
('1x'/'1.5x'/'2x') and should return a string if there's only '1x'.
Bug: T244405
Change-Id: I69ddb1f9f97d06253b661caf112b48343cd2453f
Add getAvailableLogos static method and wgLogos config variable
Longterm we'll phase out wgLogo and wgLogoHD for this more extendable
config.
wgLogoHD is marked as deprecated. wgLogo continues to function as before
when wgLogos doesn't exist to cause minimum disruption.
From now on all logos should be accessed via getAvailableLogos. Patches
in Minerva and Vector follow. See I00899c16c0325f36b671baf17e88c2b5187b3526,
I569e0d800e147eabc7852567acd140108613f074 and
I013bd0904fe8c55efa49d14e84cf06ec1412896f.
Bug: T232140
Change-Id: I66a971631c623cc94b58eb0e5e5bad804789bf1c
All mediawiki.skinning modules are repurposed as variants of the
ResourceLoaderSkinModule and those ResourceLoader modules are marked for
deprecation. Skins will now be encouraged to use the ResourceLoaderSkinModule
class themselves as part of their own style module rather than using a
module defined in core.
Bug: T118134
Bug: T114695
Change-Id: I4bc8b9b4da1c16eed34f3a517ec695019381e764
This existed for internal use by OutputPage, which is no longer
the case as of I11b390f2e4f5e7db.
Also move the unit tests from OutputPageTest,
to ResourceLoaderSkinModuleTest.
Change-Id: I8b23f976f5f89b1005b387a827f75031f5c96141
* Ignore getLogoData() which is a one-line proxy to ::getLogo,
that can't really be tested because static methods can't be stubbed.
It exists so that this method can be stubbed instead. The actual
method is already covered.
* Simplify @covers for getStyles() to allow indirect coverage within
the class because it's intended as a higher-level integration tests.
The other tests in the suite still cover a specific method only.
Change-Id: I1445a016c1f12a6d8ceaaf745023a28cf20e5371
Clean up use of @codingStandardsIgnore
- @codingStandardsIgnoreFile -> phpcs:ignoreFile
- @codingStandardsIgnoreLine -> phpcs:ignore
- @codingStandardsIgnoreStart -> phpcs:disable
- @codingStandardsIgnoreEnd -> phpcs:enable
For phpcs:disable always the necessary sniffs are provided.
Some start/end pairs are changed to line ignore
Change-Id: I92ef235849bcc349c69e53504e664a155dd162c8
SVGs could already be used through $wgLogo. However, if a PNG fallback
is desired for older browsers, using SVGs was previously not possible.
This commit adds support for using an SVG image in $wgLogoHD and,
using $wgLogo as the fallback image.
Usage example:
> $wgLogo = '/path/to/png';
> $wgLogoHD = [
> 'svg' => 'path/to/svg',
> ];
Note: When the 'svg' key is set in $wgLogoHD, any '1.5x' and '2x' keys will
no longer be used because SVGs can render optimally on any screen sizes.
@Reedy, @Krinkle and @Brion VIBBER helped me alot with this.
Bug: T86229
Change-Id: I6197d96ce9110f4711ef2c4b198445bc5c6ae110