This requires 1.42 for some new names
Changes to the use statements done automatically via script
Addition of missing use statement done manually
Change-Id: I0f43f4db86de2990c8902a36976923ad9f0ae67a
The use of "HookHandlers" attribute in extension.json makes it possible
to inject services into hook handler classes in a future patch.
Bug: T338435
Change-Id: Iadeed8e4735f95387f2faed4bc4305327bff3c8a
WikiPage::factory() is deprecated since 1.36 and should be replaced
with WikiPageFactory::newFromTitle().
Bug: T297688
Change-Id: I6c754b872c3b60ad724af8c18faacbf7320579fa
::doUserEditContent() is available since 1.36 as a replacement
for ::doEditContent(), which has been deprecated. Bump the
required version of MediaWiki to 1.36 accordingly.
Bug: T255507
Change-Id: I5d19b24031872105a27e886242c8d580ad278354
This code was a valiant but futile attempt to break a cyclic reference
cycle, copied no doubt from similar code in
tests/phpunit/includes/parser/TagHooksTest.php in core. However,
there are other cyclic references to Parser, including in StripState,
and unit test code shouldn't really be trying to optimize for memory
usage in any case.
Bug: T275160
Change-Id: I0917290d4ade8675b2d0eac17a22682c9c1b4a85
The replacement, Parser::getTags(), has been in MediaWiki for over a decade
(since sometime before 1.11).
Bug: T275160
Change-Id: Ib708e3f84aa871de84aa56561c875f4a85bb000c
For example, <templatestyles wrapper="a[href]" /> fails with an
InvalidArgumentException very late in the process, long after
the actual validation in TemplateStylesHooks::validateExtraWrapper()
was done. This happens because validateExtraWrapper() works on a
proper tree (where the [href] from the example is a nested object),
but flattens this tree in the end via toTokenArray(). This
flattened array ends in StyleRuleSanitizer::doSanitize() where it
is added to a ComponentValueList – which expects a tree.
The only change in this patch is that the object structure is not
flattened any more. That's all.
Bug: T258093
Change-Id: I5dc04611f91fe672da706f31fa8d0c254e3123d3
This reverts commit eb94a40c3e.
Reason for revert: autopatrol status wasn't included in the
use of PageUpdater, revert for now and reapply properly with
autopatrol later.
Bug: T252179
Change-Id: I38e29e607bc01146ccab00ef8e10d59b769e4044
Extensions can register additional namespaces by setting the
"TemplateStylesNamespaces" attribte in their extension.json. This change is
analogous to Ia5d34cb78fa6af.
There isn't really a simpler way to do this here, as the config setting uses
namespaces as keys, while the attribute is using them as values. Furthermore,
keys with falsey values are ignored in the config setting, and attributes can't
use the same setting architecture, as array_merge_recursive doesn't maintain
numeric keys.
Bug: T200914
Depends-On: I9e62a02ed2044c847e9ab2dcdfab094001f88986
Change-Id: I2fa9b822ee39bcc5f95a293c8c4aad4d53ede30a
The wrapper attribute may contain an extra CSS simple selector to
include when prefixing. For example, including a template as
<templatestyles src="..." wrapper="div.my-template"/> would transform
.foo .bar { color:red; }
into
.mw-parser-output div.my-template .foo .bar{color:red}
This can allow particular templates to opt in to the "styles are scoped
to the template itself" model that was desired by some when
TemplateStyles was being designed; the driving use case in the linked
task is doing so for the benefit of side-by-side comparisons of the
current and sandboxed versions of a template.
Bug: T200441
Change-Id: If49d4c5be31feca95abd21452238fd10ab1916b1
Use the facility added in core change I055abdf4d to deduplicate the
embedded style rules.
Bug: T168333
Change-Id: I98c6d5ca4b474de8826b19355f15a5230aef5650
Depends-On: I055abdf4d73ec65771eaa4fe0999ec907c831568
* Fix test for TemplateStylesFontFaceAtRuleSanitizer so it's actually run
* Hack up a broken Sanitizer to test a code path in
TemplateStylesContent::sanitize() that handles such things.
* Ignore an InvalidArgumentException in TemplateStylesContent::processError()
that's not worth checking. User input can't hit that, only logic bugs.
* Ignore TemplateStylesHooks::getConfig(), it's tested but gets called
before PHPUnit starts counting.
* Test TemplateStylesHooksTest::onCodeEditorGetPageLanguage()
* Test $wgTemplateStylesDisable
* Test a back-compat code path in TemplateStylesHooks::handleTag().
Change-Id: I7078e5a353a624aa53fe72de7990b93a77b44cf6
This just hides the error if something's broken with extension
registration because skipped tests don't result in a failed suite.
Instead, explode in everybody's eyes to make it clear there's a
problem.
Change-Id: I2f1e80a1fa4b99d857671c9d1061d34449764f01
The following sniffs are failing and were disabled:
* MediaWiki.Commenting.FunctionComment.MissingParamComment
* MediaWiki.Commenting.FunctionComment.MissingReturn
* MediaWiki.FunctionComment.Missing.Protected
* MediaWiki.FunctionComment.Missing.Public
* MediaWiki.WhiteSpace.SpaceBeforeSingleLineComment.NewLineComment
Change-Id: Ic998e3f2a791bf987f826d6dd0e92a8de24be5b7
Also fold a unit test into the normal function since we don't have to
have two valid responses based on css-sanitizer version.
Change-Id: I107c8b911781924ce9cc0730257243b9cb1592a6
