Also switch one use that we missed in the rebase.
Bug: T254646
Depends-On: I632610dec1aa6bb59af5423e6f86164fc791aadd
Change-Id: I9873c889f943fcbd7d867d534a7857f20ef0c5dc
During a file import, it's inefficient to upload the image to Swift and
then download it again to compute its properties. The arrangement
predates Swift -- it was efficient at the time. Instead, use the source
path which is always available.
Change-Id: I60dfb82f577479419ea663cd996738f1e90d5d3f
Results in passing a user where previously the fallback
to $wgUser was being used, mostly in tests.
Bug: T255507
Change-Id: Iabe24315b23c0ad1272353186425e71974528d23
* Add automatic splitting of large metadata on upload or refresh. If
the reserializeMetadata option is enabled, metadata stored with PHP
serialization will be automatically reserialized to JSON.
* Inject configuration variable $wgUpdateCompatibleMetadata via
LocalRepo instead of accessing it directly.
* In refreshImageMetadata.php and rebuildImages.php, construct a new
LocalRepo with config overrides, instead of overwriting config
globals. Add a helper to RepoGroup to help with this.
* In refreshImageMetadata.php, add new options --convert-to-json and
--split which reserialize metadata and optionally split out large
items to blob storage.
Also, refreshImageMetadata.php was totally broken in the non-force mode
since metadata refresh on page view was disabled in b814245d9f. The
maintenance script was relying on newFileFromRow() magically upgrading
the row, which doesn't happen anymore. So, call maybeUpgradeRow()
directly.
Bug: T275268
Change-Id: I7bf7d9cef71641e287ca4346b568b381f4ada50e
Updates for the removal of the Revision class itself
and the various methods/hooks/variables removed in the
process, including:
- Update some documentation removing most references
to the Revision class and updating the MCR migration
notes to reflect the past tense for Revision methods.
- Change some capitalization from "Revision" to "revision"
to make it clear comments are about revisions in general,
not the Revision class in particular.
- Minor code tweaks including removing unused variables that
were around for the old hooks that were removed, and
removing the use of DeprecatablePropertyArray where no
longer needed for anything.
- Fix incorrect documentation for PageUpdater::getStatus(),
the status value changed a while ago to have revision-record
in addition to revision, and recently to only have the
revision-record, but ironically PageUpdater was never updated.
- Removed Parser::$mRevisionObject, used to be a Revision object
and was deprecated in 1.35, missed earlier because it was no
longer being set to Revision objects, always null.
- Add RevisionRecord typehints in DummyLinker to match those
in the corresponding Linker methods
This should be a no-op in terms of functionality.
Bug: T247143
Change-Id: I03bbb94fc29085855448780b1a5ad9063911ecc4
… including PHPDoc tags like `@return <type> $variableName`.
A return value doesn't have a variable name. I can see that
some people do this intentionally, repeating the variable
name that was used in the final `return $var;` at the end
of a method. This can indeed be helpful. I leave a lot of
these untouched and removed them only when it's obviously
wrong, or does not provide any additional information in
addition to what the code already says.
Change-Id: Ia18cd9f25ef658b08ad25b97a744897e2a8deffc
This undocumented hook which is only used in FlaggedRevs (and it's being
removed in If5a56a8fd5fc568) doesn't serve much purpose and can break
the file class.
Bug: T284777
Change-Id: I7ed8c01f0d0485f40307a24cc33cf3536f70c417
ForeignAPIFile::parseMetadata is a recursive function trying to parse the
metadata tree. We want to emit _error as value if the metadata returned
by API is not an array but at the same time, we broke when the function
reaches the leaves and tries to parse them making parseMetadata return _error
for all leaves instead.
This broke beta cluster. I tested this change on beta cluster and this
patch fixes it.
Bug: T275268
Change-Id: I2befa92a8f9619ba6eb990d461f0a6f0fa7a4677
* Optionally store metadata in the database in JSON format instead of
PHP serialization. The new JSON format has a top-level "envelope"
array which gives us a place to store things that are not part of the
handler metadata.
* Optionally split metadata items, putting items above a threshold into
the text table. The FileRepo and MediaHandler must both opt in.
* For staged deployment, the read side of these changes is always
active. Only the write side is configurable.
Bug: T275268
Change-Id: I876ea5c9d3a1881e278f689d2f8a3ae20240c703
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
This is slightly weird, cause we don't realllly need authority there,
it's required for creating a file description page. Good enough probably.
Manual testing:
- uploaded a new file
- uploaded a modified version of a file
- deleted old version of a file
- restored old version of a file
- rotated image with api
Change-Id: I3d6337be974d6b2c7b055fe23875ff9d36174477
Reapply the reverted commit which removed dynamic property assignment.
But continue to allow extra fields to be passed to newFromRow() for the
benefit of subclasses.
This reverts commit 9e8ff12a59.
Change-Id: Ia3c14c51541e06264891a51763a8dadde83fbab7
This reverts commit 29cd484c86.
Reason for revert: subclasses of LocalFile broke, cause they were relying on dynamic property assignment. For example OldLocalFile was loading oi_deleted this way. We could override loadFromDB, but since LocalFile is @stable to override, this becomes a breaking change. I'll leave it to Tim to re-revert in a way he thinks it's best.
Change-Id: I81e06c13128d3330972a39fb2628a1dd5f8c4658
Merge LocalFile::decodeRow() with its only caller loadFromRow(), and
replace dynamic assignment $this->$field with plain assignment. This
makes the data flow more obvious.
The point of dynamic assignment was defeated by the fact that almost
every field required some kind of normalization after loading it from
the database. There's no point looping over all fields when you need to
do something different for each field.
Dynamic assignment is retained in loadFromCache() and setProps(), where
there is less normalization.
Change-Id: Ie103884c4436ab63c29652edf3bab331a34081c9
RepoGroup::singleton(), ::destroySingletons() and ::setSingleton()
are all deprecated since 1.34.
Bug: T249020
Change-Id: Ie6c7db6331681ec96da646f945958ed8675e6b78
Some MediaHandler subclasses were setting custom properties on the File
object in order to cache file-associated state. So:
* Add File::getHandlerState() and File::setHandlerState().
* Put them in an interface, which will be used in a subsequent commit in
MediaHandler::getSizeAndMetadata().
* Use them in DjvuHandler.
* Provide a trivial implementation of the interface, for use in testing
and in the subsequent commit.
Change-Id: Ic365384ff13f7898c1203da38c4405abf03d7563
In all these cases the property is unconditionally set in
the constructor. The extra initialisation is effectively
dead code and an extra source of errors and confusion.
Change-Id: Icae13390d5ca5c14e2754f3be4eb956dd7f54ac4
None of the changed methods actually are overridden
according to codesearch, so I guess it is ok
to change signatures.
Change-Id: I35bafb303163dfc1584a13b29675b5e10cd055fd
All hooks were previously hard deprecated
in 1.35. Affected hooks:
* ArticleRevisionUndeleted - use RevisionUndeleted
* ArticleRollbackComplete - use RollbackComplete
* DiffRevisionTools - use DiffTools
* DiffViewHeader - use DifferenceEngineViewHeader
* HistoryRevisionTools - use HistoryTools
* NewRevisionFromEditComplete - use RevisionFromEditComplete
* PageContentInsertComplete - use PageSaveComplete
* PageContentSaveComplete - use PageSaveComplete
* ParserFetchTemplate - use BeforeParserFetchTemplateRevisionRecord
* RevisionInsertComplete - use RevisionRecordInserted
* TitleMoveComplete - use PageMoveComplete
* TitleMoveCompleting - use PageMoveCompleting
* UndeleteShowRevision - no replacement
Includes a fix for setting the associated rev id
of page protections, which previously was only done
using $nullRevision which was a Revision object created
if any hooks needed it; those hooks were hard deprecated
and so for WMF prod the rev id was not being set.
Bug: T247143
Depends-On: Idfa345193ae99fb2f1c9a8f8d28d8d540a6e3d62
Change-Id: I519167f76a5a3c1f5410415b2721462a3dcc3ec8
