2007-08-17 20:53:17 +00:00
|
|
|
<?php
|
2012-05-14 17:59:58 +00:00
|
|
|
/**
|
2021-08-11 12:46:34 +00:00
|
|
|
* File deletion utilities.
|
2012-05-14 17:59:58 +00:00
|
|
|
*
|
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
|
* the Free Software Foundation; either version 2 of the License, or
|
|
|
|
|
* (at your option) any later version.
|
|
|
|
|
*
|
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
|
*
|
|
|
|
|
* You should have received a copy of the GNU General Public License along
|
|
|
|
|
* with this program; if not, write to the Free Software Foundation, Inc.,
|
|
|
|
|
* 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
|
|
|
|
|
* http://www.gnu.org/copyleft/gpl.html
|
|
|
|
|
*
|
|
|
|
|
* @file
|
|
|
|
|
* @author Rob Church <robchur@gmail.com>
|
|
|
|
|
* @ingroup Media
|
|
|
|
|
*/
|
2021-05-28 22:39:28 +00:00
|
|
|
|
2017-01-18 20:55:20 +00:00
|
|
|
use MediaWiki\MediaWikiServices;
|
2021-11-25 16:02:49 +00:00
|
|
|
use MediaWiki\Page\DeletePage;
|
2021-06-01 23:27:25 +00:00
|
|
|
use MediaWiki\User\UserIdentity;
|
2007-08-17 20:53:17 +00:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* File deletion user interface
|
|
|
|
|
*
|
WARNING: HUGE COMMIT
Doxygen documentation update:
* Changed alls @addtogroup to @ingroup. @addtogroup adds the comment to the group description, but doesn't add the file, class, function, ... to the group like @ingroup does. See for example http://svn.wikimedia.org/doc/group__SpecialPage.html where it's impossible to see related files, classes, ... that should belong to that group.
* Added @file to file description, it seems that it should be explicitely decalred for file descriptions, otherwise doxygen will think that the comment document the first class, variabled, function, ... that is in that file.
* Removed some empty comments
* Removed some ?>
Added following groups:
* ExternalStorage
* JobQueue
* MaintenanceLanguage
One more thing: there are still a lot of warnings when generating the doc.
2008-05-20 17:13:28 +00:00
|
|
|
* @ingroup Media
|
2007-08-17 20:53:17 +00:00
|
|
|
*/
|
|
|
|
|
class FileDeleteForm {
|
2010-01-13 21:25:03 +00:00
|
|
|
/**
|
|
|
|
|
* Really delete the file
|
|
|
|
|
*
|
2021-08-12 13:43:04 +00:00
|
|
|
* @param Title $title
|
|
|
|
|
* @param LocalFile $file
|
|
|
|
|
* @param string|null $oldimage Archive name
|
2014-04-08 15:29:17 +00:00
|
|
|
* @param string $reason Reason of the deletion
|
|
|
|
|
* @param bool $suppress Whether to mark all deleted versions as restricted
|
2021-06-01 23:27:25 +00:00
|
|
|
* @param UserIdentity $user
|
2020-11-20 13:12:54 +00:00
|
|
|
* @param string[] $tags Tags to apply to the deletion action
|
2012-10-07 23:35:26 +00:00
|
|
|
* @throws MWException
|
Use DeletePage in FileDeleteForm and fix output of ApiDelete
- Use DeletePage in FileDeleteForm instead of
WikiPage::doDeleteArticleReal
- Properly handle scheduled deletions in FileDeleteForm: previously, a
null status value could indicate a missing page OR a scheduled
deletion, but the code always assumed the first, and it would generate
a duplicated log entry. The API response would also not contain the
"delete-scheduled" message. This has been broken since the introduction
of scheduled deletion.
- In ApiDelete, for file deletions, check whether the status is OK not
good. The two might be equivalent, but this way it's more consistent.
- Add some documentation for the Status objects returned by file-related
methods. This is still incomplete, as there are many methods using
Status and none of them says what the status could be. In particular,
this means that for now we keep checking whether the status is OK
instead of good, even though it's unclear what could produce a
non-fatal error.
- In LocalFileDeleteBatch, avoid using a class property for the returned
status, as that's hard to follow. Instead, use a local variable and
pass it around when needed.
Bug: T288758
Change-Id: I22d60c05bdd4a3ea531e63dbb9e49efc36935137
2021-10-12 12:42:16 +00:00
|
|
|
* @return Status The value can be an integer with the log ID of the deletion, or false in case of
|
|
|
|
|
* scheduled deletion.
|
2010-01-13 21:25:03 +00:00
|
|
|
*/
|
2021-08-12 13:43:04 +00:00
|
|
|
public static function doDelete( Title $title, LocalFile $file, ?string $oldimage, $reason,
|
2021-06-01 23:27:25 +00:00
|
|
|
$suppress, UserIdentity $user, $tags = []
|
2021-07-22 03:11:47 +00:00
|
|
|
): Status {
|
2013-04-20 22:49:30 +00:00
|
|
|
if ( $oldimage ) {
|
2011-11-15 18:08:34 +00:00
|
|
|
$page = null;
|
2020-02-25 22:33:18 +00:00
|
|
|
$status = $file->deleteOldFile( $oldimage, $reason, $user, $suppress );
|
2019-08-31 16:14:38 +00:00
|
|
|
if ( $status->isOK() ) {
|
2008-04-04 12:16:50 +00:00
|
|
|
// Need to do a log item
|
2012-08-19 20:44:29 +00:00
|
|
|
$logComment = wfMessage( 'deletedrevision', $oldimage )->inContentLanguage()->text();
|
Use DeletePage in FileDeleteForm and fix output of ApiDelete
- Use DeletePage in FileDeleteForm instead of
WikiPage::doDeleteArticleReal
- Properly handle scheduled deletions in FileDeleteForm: previously, a
null status value could indicate a missing page OR a scheduled
deletion, but the code always assumed the first, and it would generate
a duplicated log entry. The API response would also not contain the
"delete-scheduled" message. This has been broken since the introduction
of scheduled deletion.
- In ApiDelete, for file deletions, check whether the status is OK not
good. The two might be equivalent, but this way it's more consistent.
- Add some documentation for the Status objects returned by file-related
methods. This is still incomplete, as there are many methods using
Status and none of them says what the status could be. In particular,
this means that for now we keep checking whether the status is OK
instead of good, even though it's unclear what could produce a
non-fatal error.
- In LocalFileDeleteBatch, avoid using a class property for the returned
status, as that's hard to follow. Instead, use a local variable and
pass it around when needed.
Bug: T288758
Change-Id: I22d60c05bdd4a3ea531e63dbb9e49efc36935137
2021-10-12 12:42:16 +00:00
|
|
|
if ( trim( $reason ) !== '' ) {
|
2012-08-19 20:44:29 +00:00
|
|
|
$logComment .= wfMessage( 'colon-separator' )
|
|
|
|
|
->inContentLanguage()->text() . $reason;
|
2010-08-29 19:11:23 +00:00
|
|
|
}
|
2012-07-01 20:09:11 +00:00
|
|
|
|
|
|
|
|
$logtype = $suppress ? 'suppress' : 'delete';
|
|
|
|
|
|
|
|
|
|
$logEntry = new ManualLogEntry( $logtype, 'delete' );
|
|
|
|
|
$logEntry->setPerformer( $user );
|
|
|
|
|
$logEntry->setTarget( $title );
|
|
|
|
|
$logEntry->setComment( $logComment );
|
2019-07-07 22:07:56 +00:00
|
|
|
$logEntry->addTags( $tags );
|
2012-07-01 20:09:11 +00:00
|
|
|
$logid = $logEntry->insert();
|
|
|
|
|
$logEntry->publish( $logid );
|
2015-10-07 14:19:36 +00:00
|
|
|
|
|
|
|
|
$status->value = $logid;
|
2008-04-04 12:16:50 +00:00
|
|
|
}
|
|
|
|
|
} else {
|
2012-02-06 15:21:10 +00:00
|
|
|
$status = Status::newFatal( 'cannotdelete',
|
|
|
|
|
wfEscapeWikiText( $title->getPrefixedText() )
|
|
|
|
|
);
|
Use DeletePage in FileDeleteForm and fix output of ApiDelete
- Use DeletePage in FileDeleteForm instead of
WikiPage::doDeleteArticleReal
- Properly handle scheduled deletions in FileDeleteForm: previously, a
null status value could indicate a missing page OR a scheduled
deletion, but the code always assumed the first, and it would generate
a duplicated log entry. The API response would also not contain the
"delete-scheduled" message. This has been broken since the introduction
of scheduled deletion.
- In ApiDelete, for file deletions, check whether the status is OK not
good. The two might be equivalent, but this way it's more consistent.
- Add some documentation for the Status objects returned by file-related
methods. This is still incomplete, as there are many methods using
Status and none of them says what the status could be. In particular,
this means that for now we keep checking whether the status is OK
instead of good, even though it's unclear what could produce a
non-fatal error.
- In LocalFileDeleteBatch, avoid using a class property for the returned
status, as that's hard to follow. Instead, use a local variable and
pass it around when needed.
Bug: T288758
Change-Id: I22d60c05bdd4a3ea531e63dbb9e49efc36935137
2021-10-12 12:42:16 +00:00
|
|
|
$services = MediaWikiServices::getInstance();
|
|
|
|
|
$page = $services->getWikiPageFactory()->newFromTitle( $title );
|
2020-11-11 21:43:18 +00:00
|
|
|
'@phan-var WikiFilePage $page';
|
Use DeletePage in FileDeleteForm and fix output of ApiDelete
- Use DeletePage in FileDeleteForm instead of
WikiPage::doDeleteArticleReal
- Properly handle scheduled deletions in FileDeleteForm: previously, a
null status value could indicate a missing page OR a scheduled
deletion, but the code always assumed the first, and it would generate
a duplicated log entry. The API response would also not contain the
"delete-scheduled" message. This has been broken since the introduction
of scheduled deletion.
- In ApiDelete, for file deletions, check whether the status is OK not
good. The two might be equivalent, but this way it's more consistent.
- Add some documentation for the Status objects returned by file-related
methods. This is still incomplete, as there are many methods using
Status and none of them says what the status could be. In particular,
this means that for now we keep checking whether the status is OK
instead of good, even though it's unclear what could produce a
non-fatal error.
- In LocalFileDeleteBatch, avoid using a class property for the returned
status, as that's hard to follow. Instead, use a local variable and
pass it around when needed.
Bug: T288758
Change-Id: I22d60c05bdd4a3ea531e63dbb9e49efc36935137
2021-10-12 12:42:16 +00:00
|
|
|
$deleter = $services->getUserFactory()->newFromUserIdentity( $user );
|
|
|
|
|
$deletePage = $services->getDeletePageFactory()->newDeletePage( $page, $deleter );
|
2021-04-29 02:37:11 +00:00
|
|
|
$dbw = wfGetDB( DB_PRIMARY );
|
2016-08-19 20:17:33 +00:00
|
|
|
$dbw->startAtomic( __METHOD__ );
|
|
|
|
|
// delete the associated article first
|
Use DeletePage in FileDeleteForm and fix output of ApiDelete
- Use DeletePage in FileDeleteForm instead of
WikiPage::doDeleteArticleReal
- Properly handle scheduled deletions in FileDeleteForm: previously, a
null status value could indicate a missing page OR a scheduled
deletion, but the code always assumed the first, and it would generate
a duplicated log entry. The API response would also not contain the
"delete-scheduled" message. This has been broken since the introduction
of scheduled deletion.
- In ApiDelete, for file deletions, check whether the status is OK not
good. The two might be equivalent, but this way it's more consistent.
- Add some documentation for the Status objects returned by file-related
methods. This is still incomplete, as there are many methods using
Status and none of them says what the status could be. In particular,
this means that for now we keep checking whether the status is OK
instead of good, even though it's unclear what could produce a
non-fatal error.
- In LocalFileDeleteBatch, avoid using a class property for the returned
status, as that's hard to follow. Instead, use a local variable and
pass it around when needed.
Bug: T288758
Change-Id: I22d60c05bdd4a3ea531e63dbb9e49efc36935137
2021-10-12 12:42:16 +00:00
|
|
|
$deleteStatus = $deletePage
|
|
|
|
|
->setSuppress( $suppress )
|
|
|
|
|
->setTags( $tags ?: [] )
|
|
|
|
|
->deleteUnsafe( $reason );
|
|
|
|
|
|
|
|
|
|
// DeletePage returns a non-fatal error status if the page
|
|
|
|
|
// or revision is missing, so check for isOK() rather than isGood().
|
2016-08-19 20:17:33 +00:00
|
|
|
if ( $deleteStatus->isOK() ) {
|
2020-03-20 20:46:28 +00:00
|
|
|
$status = $file->deleteFile( $reason, $user, $suppress );
|
2016-08-19 20:17:33 +00:00
|
|
|
if ( $status->isOK() ) {
|
2021-11-25 16:02:49 +00:00
|
|
|
if ( $deletePage->deletionsWereScheduled()[DeletePage::PAGE_BASE] ) {
|
Use DeletePage in FileDeleteForm and fix output of ApiDelete
- Use DeletePage in FileDeleteForm instead of
WikiPage::doDeleteArticleReal
- Properly handle scheduled deletions in FileDeleteForm: previously, a
null status value could indicate a missing page OR a scheduled
deletion, but the code always assumed the first, and it would generate
a duplicated log entry. The API response would also not contain the
"delete-scheduled" message. This has been broken since the introduction
of scheduled deletion.
- In ApiDelete, for file deletions, check whether the status is OK not
good. The two might be equivalent, but this way it's more consistent.
- Add some documentation for the Status objects returned by file-related
methods. This is still incomplete, as there are many methods using
Status and none of them says what the status could be. In particular,
this means that for now we keep checking whether the status is OK
instead of good, even though it's unclear what could produce a
non-fatal error.
- In LocalFileDeleteBatch, avoid using a class property for the returned
status, as that's hard to follow. Instead, use a local variable and
pass it around when needed.
Bug: T288758
Change-Id: I22d60c05bdd4a3ea531e63dbb9e49efc36935137
2021-10-12 12:42:16 +00:00
|
|
|
$status->value = false;
|
2017-06-12 17:19:57 +00:00
|
|
|
} else {
|
2021-11-25 16:02:49 +00:00
|
|
|
$deletedID = $deletePage->getSuccessfulDeletionsIDs()[DeletePage::PAGE_BASE];
|
|
|
|
|
if ( $deletedID !== null ) {
|
|
|
|
|
$status->value = $deletedID;
|
Use DeletePage in FileDeleteForm and fix output of ApiDelete
- Use DeletePage in FileDeleteForm instead of
WikiPage::doDeleteArticleReal
- Properly handle scheduled deletions in FileDeleteForm: previously, a
null status value could indicate a missing page OR a scheduled
deletion, but the code always assumed the first, and it would generate
a duplicated log entry. The API response would also not contain the
"delete-scheduled" message. This has been broken since the introduction
of scheduled deletion.
- In ApiDelete, for file deletions, check whether the status is OK not
good. The two might be equivalent, but this way it's more consistent.
- Add some documentation for the Status objects returned by file-related
methods. This is still incomplete, as there are many methods using
Status and none of them says what the status could be. In particular,
this means that for now we keep checking whether the status is OK
instead of good, even though it's unclear what could produce a
non-fatal error.
- In LocalFileDeleteBatch, avoid using a class property for the returned
status, as that's hard to follow. Instead, use a local variable and
pass it around when needed.
Bug: T288758
Change-Id: I22d60c05bdd4a3ea531e63dbb9e49efc36935137
2021-10-12 12:42:16 +00:00
|
|
|
} else {
|
|
|
|
|
// Means that the page/revision didn't exist, so create a log entry here.
|
|
|
|
|
$logtype = $suppress ? 'suppress' : 'delete';
|
|
|
|
|
$logEntry = new ManualLogEntry( $logtype, 'delete' );
|
|
|
|
|
$logEntry->setPerformer( $user );
|
|
|
|
|
$logEntry->setTarget( $title );
|
|
|
|
|
$logEntry->setComment( $reason );
|
|
|
|
|
$logEntry->addTags( $tags );
|
|
|
|
|
$logid = $logEntry->insert();
|
|
|
|
|
$dbw->onTransactionPreCommitOrIdle(
|
|
|
|
|
static function () use ( $logEntry, $logid ) {
|
|
|
|
|
$logEntry->publish( $logid );
|
|
|
|
|
},
|
|
|
|
|
__METHOD__
|
|
|
|
|
);
|
|
|
|
|
$status->value = $logid;
|
|
|
|
|
}
|
2017-06-12 17:19:57 +00:00
|
|
|
}
|
2015-10-07 18:48:23 +00:00
|
|
|
$dbw->endAtomic( __METHOD__ );
|
2016-08-19 20:17:33 +00:00
|
|
|
} else {
|
|
|
|
|
// Page deleted but file still there? rollback page delete
|
2017-02-07 13:31:46 +00:00
|
|
|
$lbFactory = MediaWikiServices::getInstance()->getDBLoadBalancerFactory();
|
2021-09-02 19:14:52 +00:00
|
|
|
$lbFactory->rollbackPrimaryChanges( __METHOD__ );
|
2008-04-04 12:16:50 +00:00
|
|
|
}
|
2016-08-19 20:17:33 +00:00
|
|
|
} else {
|
|
|
|
|
$dbw->endAtomic( __METHOD__ );
|
2008-04-04 12:16:50 +00:00
|
|
|
}
|
|
|
|
|
}
|
2011-11-15 18:08:34 +00:00
|
|
|
|
2012-02-06 15:21:10 +00:00
|
|
|
if ( $status->isOK() ) {
|
2021-06-01 23:27:25 +00:00
|
|
|
$legacyUser = MediaWikiServices::getInstance()
|
|
|
|
|
->getUserFactory()
|
|
|
|
|
->newFromUserIdentity( $user );
|
|
|
|
|
Hooks::runner()->onFileDeleteComplete( $file, $oldimage, $page, $legacyUser, $reason );
|
2011-11-15 18:08:34 +00:00
|
|
|
}
|
2008-04-14 07:45:50 +00:00
|
|
|
|
2008-04-04 12:16:50 +00:00
|
|
|
return $status;
|
|
|
|
|
}
|
2007-09-13 08:51:13 +00:00
|
|
|
|
2007-08-17 20:53:17 +00:00
|
|
|
/**
|
|
|
|
|
* Is the provided `oldimage` value valid?
|
|
|
|
|
*
|
2014-04-20 19:16:57 +00:00
|
|
|
* @param string $oldimage
|
2007-08-17 20:53:17 +00:00
|
|
|
* @return bool
|
|
|
|
|
*/
|
2013-02-03 20:05:24 +00:00
|
|
|
public static function isValidOldSpec( $oldimage ) {
|
2008-04-04 13:59:04 +00:00
|
|
|
return strlen( $oldimage ) >= 16
|
|
|
|
|
&& strpos( $oldimage, '/' ) === false
|
|
|
|
|
&& strpos( $oldimage, '\\' ) === false;
|
2007-08-17 20:53:17 +00:00
|
|
|
}
|
2008-01-25 10:15:46 +00:00
|
|
|
}
|