With this patch deprecation warnings will be emitted
if $wgUser is accessed or written into. The only pattern
of usage still allowed is
$oldUser = $wgUser;
$wgUser = $newUser;
// Do something
$wgUser = $oldUser;
Once there is no deprecation warnings, we know that nothing
legitimately depends on $wgUser being set, so we can safely
remove the code that's still allowed as well.
Bug: T267861
Change-Id: Ia1c42b3a32acd0e2bb9b0e93f1dc3c82640dcb22
The software behind this is abandoned and we are migrating djvu metadata
to json instead.
This doesn't affect production as we already use djvudump
Bug: T275268
Change-Id: If45ae5746ba91ba305f93603dc1e3aafba80a369
I10d2b32bd95316e1331b5eb88ef57de55c3ca1a1 removed the last usage of MediaWikiTestCaseTrait, thus the use statement can be removed.
Change-Id: I05b3b56abc8079abd294e453c78128858ef8ea7d
Results in passing a user where previously the fallback
to $wgUser was being used, mostly in tests.
Bug: T255507
Change-Id: Iabe24315b23c0ad1272353186425e71974528d23
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
array_fill_keys() was introduced in PHP 5.2.0 and works like
array_flip() except that it does only one thing (copying keys) instead
of two things (copying keys and values). That makes it faster and more
obvious.
When array_flip() calls were paired, I left them as is, because that
pattern is too cute. I couldn't kill something so cute.
Sometimes it was hard to figure out whether the values in array_flip()
result were used. That's the point of this change. If you use
array_fill_keys(), the intention is obvious.
Change-Id: If8d340a8bc816a15afec37e64f00106ae45e10ed
Image metadata is usually a serialized string representing an array.
Passing the string around internally and having everything unserialize
it is an awkward convention.
Also, many image handlers were reading the file twice: once for
getMetadata() and again for getImageSize(). Often getMetadata()
would actually read the width and height and then throw it away.
So, in filerepo:
* Add File::getMetadataItem(), which promises to allow partial
loading of metadata per my proposal on T275268 in a future commit.
* Add File::getMetadataArray(), which returns the unserialized array.
Some file handlers were returning non-serializable strings from
getMetadata(), so I gave them a legacy array form ['_error' => ...]
* Changed MWFileProps to return the array form of metadata.
* Deprecate the weird File::getImageSize(). It was apparently not
called by anything, but was overridden by UnregisteredLocalFile.
* Wrap serialize/unserialize with File::getMetadataForDb() and
File::loadMetadataFromDb() in preparation for T275268.
In MediaHandler:
* Merged MediaHandler::getImageSize() and MediaHandler::getMetadata()
into getSizeAndMetadata(). Deprecated the old methods.
* Instead of isMetadataValid() we now have isFileMetadataValid(), which
only gets a File object, so it can decide what data it needs to load.
* Simplified getPageDimensions() by having it return false for non-paged
media. It was not called in that case, but was implemented anyway.
In specific handlers:
* Rename DjVuHandler::getUnserializedMetadata() and
extractTreesFromMetadata() for clarity. "Metadata" in these function
names meant an XML string.
* Updated DjVuImage::getImageSize() to provide image sizes in the new
style.
* In ExifBitmapHandler, getRotationForExif() now takes just the
Orientation tag, rather than a serialized string. Also renamed for
clarity.
* In GIFMetadataExtractor, return the width, height and bits per channel
instead of throwing them away. There was some conflation in
decodeBPP() which I picked apart. Refer to GIF89a section 18.
* In JpegMetadataExtractor, process the SOF0/SOF2 segment to extract
bits per channel, width, height and components (channel count). This
is essentially a port of PHP's getimagesize(), so should be bugwards
compatible.
* In PNGMetadataExtractor, return the width and height, which were
previously assigned to unused local variables. I verified the
implementation by referring to the specification.
* In SvgHandler, retain the version validation from unpackMetadata(),
but rename the function since it now takes an array as input.
In tests:
* In ExifBitmapTest, refactored some tests by using a provider.
* In GIFHandlerTest and PNGHandlerTest, I removed the tests in which
getMetadata() returns null, since it doesn't make sense when ported to
getMetadataArray(). I added tests for empty arrays instead.
* In tests, I retained serialization of input data since I figure it's
useful to confirm that existing database rows will continue to be read
correctly. I removed serialization of expected values, replacing them
with plain data.
* In tests, I replaced access to private class constants like
BROKEN_FILE with string literals, since stability is essential. If
the class constant changes, the test should fail.
Elsewhere:
* In maintenance/refreshImageMetadata.php, I removed the check for
shrinking image metadata, since it's not easy to implement and is
not future compatible. Image metadata is expected to shrink in
future.
Bug: T275268
Change-Id: I039785d5b6439d71dcc21dcb972177dba5c3a67d
Hooks::register and Hooks::clear are deprecated (the second one is
hard deprecated, leading to deprecation warnings). Use
HookContainer::register and HookContainer::clear instead.
Bug: T281613
Change-Id: I10d2b32bd95316e1331b5eb88ef57de55c3ca1a1
This character is no longer required here.
It was added to ensure correct display of parentheses in mixed
LTR/RTL environment, for example an interlanguage link from
an RTL wiki to an LTR language with parentheses in its name.
However, the Unicode bidirectional algorithm was updated
to handle parentheses more cleverly and automatically,
making manual adjustment with RTL/LRM unnecessary.
This update was implemented years ago in all browsers and
operating systems. I've tested this in Firefox, Chrome, Edge,
and Internet Explorer 11, and it works correctly without
the RLM/LRM characters.
Parser tests are updated accordingly.
Bug: T280435
Change-Id: I63107f623ade3b8367eae579a8e96d7e2c18b747
Our PortableInfobox extension uses the HTML5 <aside> tag in its generated HTML.
This tag isn't recognized as a block element (in the way e.g. <div> is) by the
legacy parser, resulting in some spurious empty paragraphs in the output.
As a fix, make the legacy parser aware of <aside> tags to avoid unnecessary
p-wrapping. Also add <aside> to the Sanitizer's internal attribute check.
I3e57f55ac69d2c1ee8a1d41c21b692e56fc7e628 takes care of updating Parsoid-PHP
accordingly.
Bug: T278565
Change-Id: I89dbdf7770e13e1b62320228a366c64e64217b0b
This fails without the follow-up patch with the same exception as on the
task
Bug: T276476
Follow-Up: I014da3a333f8ee6ca623b98c415b8d9f9d1be084
Change-Id: Ib61e9ea44a6fdc31e10b89c3504cecec5b9fd208
This property was deprecated in 1.35.
Code search:
https://codesearch.wmcloud.org/search/?q=mTagHooks&i=nope&files=&excludeFiles=&repos=
Dependencies below are for WMF-deployed code. Other uses in
non-WMF-deployed code have been patched in:
* I435b0d1ccae9d9bf6fff85dc3e79d3c4b447eb37
* I85ef0e6ce3f0c818df85809d39259d13b56d966c
* Idab6c9475f78ff4040061f2f317560bbe41666d8
Bug: T275160
Depends-On: Ic5445471d770e396421a4fb2bcfbe1490a77e1bf
Depends-On: Ib708e3f84aa871de84aa56561c875f4a85bb000c
Change-Id: I42e23b101e870b66d169cbb731a0359e90f46265
This has effectively been the case since 1.35; this just cleans up the
remaining code which assumed it still needed to explicitly call
Parser::firstCallInit() on a newly-constructed Parser.
Bug: T250444
Change-Id: I340947c721172f12ff413322b4283627c0b0b3a4
We lost some insight in c44a395 because we're no longer analysing the
entire dom as a serialized string, but instead running our regexp on
individual text nodes.
This patch as written here just allows for the space to be at the start
of the text node. However, some git spelunking shows that in 9dc65ef,
the condition for there being a non-whitespace character previous to the
space was only because armoring French spacing happened before
doBlockLevels and wanted to protect indent pre's.
That's certainly not the case anymore, so we can probably get away with
dropping the condition altogether now.
Bug: T275918
Change-Id: I654a09b0f98937379b9fad3f325134ead7f2d8a6
This also means we don't need to take special care for French spacing in
attributes, since it's no longer applied there.
Adds a test that captures this change.
Note that the test "Nowiki and french spacing" wonders whether this
escaping should be applied to nowiki content.
Bug: T255007
Change-Id: Ic8965e81882d7cf024bdced437f684064a30ac86
This validates langconvert's "from" and "to" arguments as valid BCP 47 tags. For example, it will accept "sr-Cyrl" and "sr-cyrl" and reject the non-standard internal MediaWiki code "sr-ec". I made the BCP 47 matching case insensitive as that seems to conform with how MediaWiki handles it elsewhere and case sensitive matching would probably be a headache for users.
Bug: T271758
Change-Id: I9f765fe650279820d61c3a7e499ca99468df3d14
