Some methods on LocalFile will fatal if called on a non-existing file.
ApiQueryImageInfo did not take that into account.
This patch changes LocalFile to avoid fatal errors, and ApiQueryImageInfo
to not try and report information on non-existing files.
NOTE: the modified code has NO test coverage! This should be fixed
before this patch is applied, or the patch needs to be thoroughly tested
manually.
Bug: T221812
Change-Id: I9b74545a393d1b7a25c8262d4fe37a6492bbc11e
This removes most of the pre-actor user and user_text columns, and the
$wgActorTableSchemaMigrationStage setting that used to determine
whether the columns were used.
rev_user and rev_user_text remain in the code, as on Wikimedia wikis the
revision table is too large to alter at this time. A future change will
combine that with the removal of rev_comment, rev_content_model, and
rev_content_format (and the addition of rev_comment_id and rev_actor).
ActorMigration's constructor continues to take a $stage parameter, and
continues to have the logic for handling it, for the benefit of
extensions that might need their own migration process. Code using
ActorMigration for accessing the core fields should be updated to use
the new actor fields directly. That will be done for in a followup.
Bug: T188327
Change-Id: Id35544b879af1cd708f3efd303fce8d9a1b9eb02
This allows us to remove many suppressions for phan false positives.
Bug: T231636
Depends-On: I82a279e1f7b0fdefd3bb712e46c7d0665429d065
Change-Id: I5c251e9584a1ae9fb1577afcafb5001e0dcd41c7
$tags can be `null` as seen in most cases and this causes failures,
so, the safer path is to make sure if $tags is a null, do nothing.
Change-Id: I5b7e39adba5d08fdcd42c437a72a391be98c8695
And also update approximated counts, which for the most part are lower
than reported (hooray!)
Bug: T231636
Depends-On: Ica50297ec7c71a81ba2204f9763499da925067bd
Change-Id: I78354bf5f0c831108c8f606e50c87cf6bc00d8bd
The purge() method handles purging of both file cache and CDN, using
a PRESEND deferred update. This avoids code duplication and missing
file cache purge calls.
Also:
* Migrate HTMLCacheUpdate callers to just directly using HTMLCacheUpdateJob
* Add HtmlFileCacheUpdate class and defer such updates just like with CDN
* Simplify HTMLCacheUpdate constructor parameters
* Remove BacklinkCache::clear() calls which do nothing since the backlink
query does not actually happen until the job runs
Change-Id: Ic453b189a40109a73a9426538608eea87a76befa
Fixes a wfFindFile/wfLocalFile mixup in I9437494d.
Also restore the original behavior in Linker::makeBrokenImageLinkObj
for paranoia - findFile has a local cache so calling it and then
discarding the results is not completely a noop.
Bug: T226448
Change-Id: Ibb9d6f6383eb96ba27e0edd60423552e5cea4688
The FileRepo extension API allows to specify factory methods that
FileRepo implementations will use to instantiate File instances.
Currently, the default static constructors in LocalFile and OldLocalFile
do not use Late Static Binding, so every subclass is forced to re-implement them,
even if they would not need any custom logic. Switching to Late Static Binding
(available since PHP 5.3) allows File implementors to reduce boilerplate
if they do not need to overwrite the existing logic.
Change-Id: Id8f6f5362b68269c2a3232796a1703be14116dd5
These global functions were deprecated in 1.34 and services made
available to replace them. See services below;
* wfFindFile() - MediaWikiServices::getInstance()->getRepoGroup()->findFile()
* wfLocalFind() - MediaWikiServices::getInstance()->getRepoGroup()->getLocalRepo()->newFile()
NOTES:
* wfFindFile() and wfLocalFind() usages in tests have been ignored
in this change per @Timo's comments about state of objects.
* includes/upload/UploadBase.php also maintained for now as it causes
some failures I don't fully understand, will investigate and handle
it in a follow up patch.
* Also, includes/MovePage.php
Change-Id: I9437494de003f40fbe591321da7b42d16bb732d6
Wikimedia\quietCall() is deprecated and AtEase is here for use.
I would have loved to do restoreWarnings() and suppressWarnings()
in this same patch set but will continue the work for a later patch.
Bug: T182273
Change-Id: I43e3a5f378c99b5c40883b35ba133cbd126fc433
When importing a previously archived file revision, \OldLocalFile::uploadOld()
calls \LocalFile::publishTo() with $dstRel pointing to a location in the
archive. It does not make sense to create a new archive file name for a file
that is already in the archive. Instead, use the existing archive file name.
* Note how $archiveName is not used in the code below, except as part of the
returned status.
* $archiveRel ends in \FileRepo::publishBatch(), but is barely used there
except for (again) the status.
* \FileRepo::publishBatch() makes use of the dirname() extracted from
$archiveRel. This patch does not make changes to this path, only to the
file name.
This is the most trivial patch we could think of to fix the bug that the
return value is not the documented one ("On success, the value member
contains the archive name").
This will be covered by the test introduced in I15fad26.
Bug: T200001
Bug: T210755
Change-Id: I28b782e9b41ed78ac1674111094335849e15ba49
This change s adds 'revert' as a separate log action for file reverts, as it
allows special formatting of log entries and revisions in UI and filtering
for file reverts specifically.
Even though there are no log entries with this log action right now, it does
seem that this was intended as some point, as there are corresponding
test cases in UploadLogFormatterTest, and is listed in
$wgLogActionsHandlers and https://www.mediawiki.org/wiki/API:Logevents
as well. Furthermore, the i18n message 'logentry-upload-revert' already
existed before this change.
Because this functionality can not be provided by tags, the 'mw-undo' tag
is not suited for this use case. However, it could be added additionally to
all log entries with this log action..
Bug: T60209
Change-Id: Ie1ccd8053dc5de58b2297a8460219f0233aab968
This removes most of the pre-CommentStore text columns, and the
$wgCommentTableSchemaMigrationStage setting that used to determine
whether the columns were used.
rev_comment remains in the code, as on Wikimedia wikis the revision
table is too large to alter at this time. A future change will combine
that with the removal of rev_user_text, rev_content_model, and
rev_content_format (and the addition of rev_comment_id and rev_actor).
CommentStore's constructor continues to take a $stage parameter, and
continues to have the logic for handling it, for the benefit of
extensions that might need their own migration process.
Bug: T166733
Change-Id: I1479c73774e01ead1490adf6128f820c09bce9d4
I argue that these comments don't provide any additional information.
I think the code explains itself already.
Change-Id: I7b495dfde5e8b27a4cdd4bfcf84d388ffc2db5e3
Before Iab5f5215, the call to CommentStore::insertWithTempTable() also
happened to populate image_comment_temp for the later call to
insertSelect() when moving rows from the image table to oldimage or
filearchive. There was nothing in the image table itself that needed
updating.
In that change those calls were changed to CommentStore::insert(), but
it was missed that in that case we do have to update the image table
itself.
Bug: T207419
Change-Id: I26c417c9ab8a9160a7c7ec548ffdfabf17f01980
I have no idea why this suddenly started raising an error rather than it
doing so since February (I0dd7258fe). But this should fix it.
Bug: T207419
Change-Id: Id97e1c7c2655d90928c777bc3377e5ea23f49f6b
When this was originally written, the plan was to read both the old and
new fields during the transition period, while stopping writes to them
midway through. It turns out that the WHERE conditions to do read-both
correctly are generally not handled well by the database and working
around that would require a lot of complicated code (see what's being
removed from ApiQueryUserContribs here, for example).
We can simplify things greatly by instead having it write both fields
during the transition period, reading from the old for the first part
and the new for the second part, as is being done for MCR.
Bug: T204669
Change-Id: I4764c1c7883dc1003cb12729455c8107319f70b1
Depends-On: I845f6ae462f2539ebd35cbb5f2ca8b5714e2c1fb
Depends-On: I88b31b977543fdbdf69f8c1158e77e448df94e11
image_comment_temp was always intended to be temporary, until an
expensive schema change on Wikimedia Commons's image table could be
done. Now that that has been done, stop writing image_comment_temp and
add a migration script to copy existing data into img_description_id.
Ic8efeddc will remove the reads from image_comment_temp and drop the
image_comment_temp table.
Bug: T188132
Change-Id: Iab5f521577a415b2dc213b517ee8a0dca4fdd0aa
When aliasing a field to null, it has to be aliased to the string 'NULL'
rather than PHP null.
Bug: T198687
Change-Id: I6096f306b97022da781eaabeb15e502f391673a9
Find: /isset\(\s*([^()]+?)\s*\)\s*\?\s*\1\s*:\s*/
Replace with: '\1 ?? '
(Everywhere except includes/PHPVersionCheck.php)
(Then, manually fix some line length and indentation issues)
Then manually reviewed the replacements for cases where confusing
operator precedence would result in incorrect results
(fixing those in I478db046a1cc162c6767003ce45c9b56270f3372).
Change-Id: I33b421c8cb11cdd4ce896488c9ff5313f03a38cf
When uploading multiple file revisions with fitting text revisions to
core the UploadRevisionImporter will create a unwanted NullRevision on
the file page.
This NullRevision originates from LocalFile:upload() and is added there
in recordUpload2 as part of the normal upload process. There it is meant
to leave a hint on the text revision history.
This whole area is in need of heavy refactoring. But since the issue is
blocking the current implementation of the FileImporter extension, a
parameter is added to control the creation of that NullRevision.
Bug: T193621
Change-Id: I57c947eb63a7627ab1eec850cdf5e076f5f62df5
