* 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
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
wikimedia/css-sanitizer provides a real CSS parser, which should be
safer than poking at things with regular expressions.
Instead of the strange hybrid model that tried to both process inline
CSS and save CSS when the template is saved, it now looks for
<templatestyles src="Title" /> during the parse to do all the
transclusion of styles.
The output method is "<style> tags in the body", pending someone
implementing T160563.
It now also registers a "sanitized-css" content model, which should pick
up the CSS syntax highlighting and will validate the submitted CSS on
submit and prevent a save if it's not valid.
This patch also takes advantage of LGPL-2.x § 3 to relicense the
extension as GPL-2.0+, although at this point none of the LGPL code
remains anyway.
Bug: T133408
Bug: T136054
Bug: T135788
Bug: T135789
Change-Id: I993e6f18d32a43aac8398743133d227b05133bbd
Depends-On: If4eb5bf71f94fa366ec4eddb6964e8f4df6b824a
