Instead of having two conflicting filerepo configurations, one at
/tmp/test-repo and another at a randomized path, and populating the one
that isn't used with files, let's just have a single upload directory,
populate it with files, and then actually use those files.
This fixes a set of confusing system-dependent parser test failures. In
the failure scenario, the file upload would be recorded, but then
invalid JPEG metadata would trigger LocalFile::loadFromFile(), which
would look for the file in the wrong place and mark it missing. Then
parser tests would fail due to image links being broken (red).
This is probably not as nice as the fake in-memory repo used by
NewParserTest, but this approach does provide a richer integration test.
This is a conservative fix that just fixes the things that are terribly
broken rather than making new things.
Also:
* Clear the RepoGroup singleton, for completeness, since it doesn't
make sense to set $wgLocalRepo without clearing it. Since we now set up
a similar repo at initialisation to the one set up with each test, it
probably doesn't have any effect.
* Warn if gd is not present since this causes 49 test failures.
* Use glob patterns in teardownUploadDir() instead of requiring every
file to be individually listed. This fixes an error due to failure to
delete a 240px file.
Change-Id: I56a0e0d1cb363b40cf19c735e00cbb8929c1401a
* Split tidy implementations into a class hierarchy
* Bring all tidy configuration into a single associative array and
deprecate the old configuration.
* Remove $wgAlwaysUseTidy
This is preparatory to replacement of Tidy (T89331). I used the name
"Raggett" for things relating to Dave Raggett's Tidy, since if we use
"tidy" to mean the new abstract system as well as Raggett's tidy, it
gets confusing.
Change-Id: I77af1a16cbbb47fc226d05fb9aad56c58e8910b5
This seems to cause redirect loops in current Firefox instead.
This reverts commit a89a21990e.
Bug: T106793
Change-Id: I18fac8ab0f94e2df8476131b132c9866902a02c4
Similar to 7b4df0e12e,
but for apostrophe instead of tilde and for Opera
instead of Chrome.
Bug: T106793
Change-Id: Ic54390434cebcc76a6c8ab49acc164d36e0cdff6
Invalid HTML5 character entities become instances of UTF8_REPLACEMENT,
so we also ensure that checkCSS notices this and emits the proper
human-friendly sanitization notice.
Change-Id: I76cef7c772b1e3eba0af8dab6403e9100beab03a
Because of a missing condition, it generally only had an effect on
output type Parser::OT_WIKI, and thus {{msgnw:}} would strip comments
except when substituted during a pre-save transform.
Bug: T98841
Change-Id: I1e47696434fe87475f9902e6bfb8990566456e2f
* \s matches the trim on the line.
* Since leading space is ok for table start tags, and you can use them
in ":" context, you should be able to compose the two together.
Bug: T105238
Change-Id: Id08e24e5dd2bb8ca09453adec87b21225df4a840
As of 155d555b83, we now redirect variations on hex escapes
into their canonical form. This was causing '~' to be redirected
to %7E. However google chrome seems to canonicalize %7E back
into ~, causing a redirect loop.
RFC 3986 says ~ is unreserved, so not hex encoding it should be
fine. To quote: "For consistency, percent-encoded octets in the
ranges of...tilde (%7E) should not be created by URI producers"
Bug: T105265
Change-Id: I01556eee496e2fb540de8ff09c082c1fedddb5f7
* Urlencode and extension tags don't play nice. The current behaviour
is pretty broken. For example,
{{urlencode:<pre id="one">two</pre>}}
outputs
<pre id="one">two</pre>
which isn't exactly urlencoded.
* Just drop the unexpanded content; anything more seems unsafe. There's
precedent for this already in anchorencode.
* Noticed in the infobox caption for enwiki/%22F%22_Is_for_Fugitive
Change-Id: I0ec5d2fdeb71f762036464f65029afd029e8b4a1
If someone renames a section but wants old targeted links to still work,
<span id="old-anchor"></span> is the usual solution. And sometimes
people put it inside the section header markup, like
== <span id="old-anchor"></span>New name ==
since putting it before makes it be considered part of the previous section
while putting it after causes the browser to scroll the section header
off the screen.
But this has the unfortunate side effect that the TOC text for that
section will be "<span></span>New name". We should strip that useless
empty span.
Bug: T96153
Change-Id: I47a33ceb79d48f6d0c38fa3b3814a378feb5e31e
Escape > characters in attributes, so we don't confuse post-processing,
like LanguageConverter.
Bug: T73394
Change-Id: I768e2a12c7b6ba635e6c8571676b8c776b16bf72
* Remove redundant @licence/@license from test suite files.
They already have full licence headers. And @licence raises a
warning in Doxygen.
* Fix weird messes of comments inside comments and other things.
Change-Id: I38da8ca76330f72b8dc22b0ecf1ea69d5ea55ede
Follows-up 6c7480e5f0, d2a6a73d2.
The should stop the § character from being indexed by Google et al.
Bug: T18691
Bug: T93000
Change-Id: Ie9e334e973e3ded270f1897a2c3816d9df739fc0
* There's a branch path in the sanitizer that depends on $wgUseTidy,
which means the test output differs from on wiki.
* In general, we should set these variables to match the wiki behaviour
in tests.
* Exposes T92892, Sanitizer removes empty tags when tidy is disabled.
* Tweaked tests for T19663 to use an extension tag to show that
HTML5 tags with non-word characters make it through the parser
intact (before being ultimately sanitized).
Change-Id: I09c72fd739e11a8b757f37dc4c790758d782ad73