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
|
DeletePage: add option to delete the associated talk page
Currently this is implemented internally as a second method call. In the
future, it might be possible to optimize the implementation, e.g. to
reduce the amount of DB queries/jobs etc. without changing anything for
callers.
Since the implementation of e.g. the result getters is generic, a future
commit may add an option to delete subpages with relatively low effort.
The revision limit for big deletions is now using the total number of
revisions (base page + talk page). This is because both deletions would
happen in the same main transaction, and we presumably want to optimize
the deletion as a whole, not as two separated steps. This would become
even more important if the aforementioned improvements are ever
implemented. Note, the whole concept of "big deletion" might have been
superseded by batched deletions in the author's opinion, but as long as
such a limit exists, it should serve its purpose.
The current interpretation of the associated talk option is that the
request is validated, and an exception is raised if we cannot delete the
associated talk, as opposed to silently ignoring the parameter if the
talk cannot be deleted. The only exception to this is that it will not
fail hard if the talk page turns out not to exist by the time the
deletion is attempted, as that's hard to foresee due to race conditions.
Note that the summary for the talk deletion is prefixed with the
delete-talk-summary-prefix message. The main reason behind this is that
the delete UI can sometimes offer an auto-generated summary like "the
only contributor was XXX" or "the content was YYY", and since this may
not apply to the talk page as well, the log entry might look confusing.
Bug: T263209
Bug: T27471
Change-Id: Ife1f4e8258a69528dd1ce8fef8ae809761aa6f1d
2021-09-01 12:56:43 +00:00
|
|
|
* @param bool $deleteTalk
|
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.
|
DeletePage: add option to delete the associated talk page
Currently this is implemented internally as a second method call. In the
future, it might be possible to optimize the implementation, e.g. to
reduce the amount of DB queries/jobs etc. without changing anything for
callers.
Since the implementation of e.g. the result getters is generic, a future
commit may add an option to delete subpages with relatively low effort.
The revision limit for big deletions is now using the total number of
revisions (base page + talk page). This is because both deletions would
happen in the same main transaction, and we presumably want to optimize
the deletion as a whole, not as two separated steps. This would become
even more important if the aforementioned improvements are ever
implemented. Note, the whole concept of "big deletion" might have been
superseded by batched deletions in the author's opinion, but as long as
such a limit exists, it should serve its purpose.
The current interpretation of the associated talk option is that the
request is validated, and an exception is raised if we cannot delete the
associated talk, as opposed to silently ignoring the parameter if the
talk cannot be deleted. The only exception to this is that it will not
fail hard if the talk page turns out not to exist by the time the
deletion is attempted, as that's hard to foresee due to race conditions.
Note that the summary for the talk deletion is prefixed with the
delete-talk-summary-prefix message. The main reason behind this is that
the delete UI can sometimes offer an auto-generated summary like "the
only contributor was XXX" or "the content was YYY", and since this may
not apply to the talk page as well, the log entry might look confusing.
Bug: T263209
Bug: T27471
Change-Id: Ife1f4e8258a69528dd1ce8fef8ae809761aa6f1d
2021-09-01 12:56:43 +00:00
|
|
|
* @throws MWException
|
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,
|
DeletePage: add option to delete the associated talk page
Currently this is implemented internally as a second method call. In the
future, it might be possible to optimize the implementation, e.g. to
reduce the amount of DB queries/jobs etc. without changing anything for
callers.
Since the implementation of e.g. the result getters is generic, a future
commit may add an option to delete subpages with relatively low effort.
The revision limit for big deletions is now using the total number of
revisions (base page + talk page). This is because both deletions would
happen in the same main transaction, and we presumably want to optimize
the deletion as a whole, not as two separated steps. This would become
even more important if the aforementioned improvements are ever
implemented. Note, the whole concept of "big deletion" might have been
superseded by batched deletions in the author's opinion, but as long as
such a limit exists, it should serve its purpose.
The current interpretation of the associated talk option is that the
request is validated, and an exception is raised if we cannot delete the
associated talk, as opposed to silently ignoring the parameter if the
talk cannot be deleted. The only exception to this is that it will not
fail hard if the talk page turns out not to exist by the time the
deletion is attempted, as that's hard to foresee due to race conditions.
Note that the summary for the talk deletion is prefixed with the
delete-talk-summary-prefix message. The main reason behind this is that
the delete UI can sometimes offer an auto-generated summary like "the
only contributor was XXX" or "the content was YYY", and since this may
not apply to the talk page as well, the log entry might look confusing.
Bug: T263209
Bug: T27471
Change-Id: Ife1f4e8258a69528dd1ce8fef8ae809761aa6f1d
2021-09-01 12:56:43 +00:00
|
|
|
$suppress, UserIdentity $user, $tags = [], bool $deleteTalk = false
|
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 );
|
DeletePage: add option to delete the associated talk page
Currently this is implemented internally as a second method call. In the
future, it might be possible to optimize the implementation, e.g. to
reduce the amount of DB queries/jobs etc. without changing anything for
callers.
Since the implementation of e.g. the result getters is generic, a future
commit may add an option to delete subpages with relatively low effort.
The revision limit for big deletions is now using the total number of
revisions (base page + talk page). This is because both deletions would
happen in the same main transaction, and we presumably want to optimize
the deletion as a whole, not as two separated steps. This would become
even more important if the aforementioned improvements are ever
implemented. Note, the whole concept of "big deletion" might have been
superseded by batched deletions in the author's opinion, but as long as
such a limit exists, it should serve its purpose.
The current interpretation of the associated talk option is that the
request is validated, and an exception is raised if we cannot delete the
associated talk, as opposed to silently ignoring the parameter if the
talk cannot be deleted. The only exception to this is that it will not
fail hard if the talk page turns out not to exist by the time the
deletion is attempted, as that's hard to foresee due to race conditions.
Note that the summary for the talk deletion is prefixed with the
delete-talk-summary-prefix message. The main reason behind this is that
the delete UI can sometimes offer an auto-generated summary like "the
only contributor was XXX" or "the content was YYY", and since this may
not apply to the talk page as well, the log entry might look confusing.
Bug: T263209
Bug: T27471
Change-Id: Ife1f4e8258a69528dd1ce8fef8ae809761aa6f1d
2021-09-01 12:56:43 +00:00
|
|
|
if ( $deleteTalk ) {
|
|
|
|
|
$checkStatus = $deletePage->canProbablyDeleteAssociatedTalk();
|
|
|
|
|
if ( !$checkStatus->isGood() ) {
|
|
|
|
|
return Status::wrap( $checkStatus );
|
|
|
|
|
}
|
|
|
|
|
$deletePage->setDeleteAssociatedTalk( true );
|
|
|
|
|
}
|
2021-04-29 02:37:11 +00:00
|
|
|
$dbw = wfGetDB( DB_PRIMARY );
|
2021-12-15 04:17:28 +00:00
|
|
|
$dbw->startAtomic( __METHOD__, $dbw::ATOMIC_CANCELABLE );
|
2016-08-19 20:17:33 +00:00
|
|
|
// 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 ?: [] )
|
2022-04-11 16:43:37 +00:00
|
|
|
->deleteIfAllowed( $reason );
|
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
|
|
|
|
|
|
|
|
// 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
|
2021-12-15 04:17:28 +00:00
|
|
|
$dbw->cancelAtomic( __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
|
|
|
}
|