When we get to FileDeleteAction is already too late: even if we call the
parent method, the other class methods will still be called due to
inheritance. So do that earlier, and don't create a FileDeleteAction at
all if the file cannot be deleted.
Bug: T295435
Change-Id: I2f9a7557518836fd22763fe3301538fe08f38fda
Unused except for DeleteAction, which now uses a custom query (similar
to the one in ContentHandler::getAutoDeleteReason). Passing the
parameter is hence hard-deprecated, and it will be removed in 1.39.
Also escalate the exception logging from wfDebug to error, since we want
to know what exceptions are being caught.
Bug: T288282
Change-Id: I91ed9574da68bc7ff36e968f016da390b6d295ed
Use getTitle() in FileDeleteAction, it's the same as using the old
$this->file.
Use a single showForm method for both classes, and a separate method to
add handy links. When switching to FormAction, the former will be
replaced by getFormFields(), the latter by postText(). However, before
doing that, the following things should be addressed:
- The onArticleConfirmDelete hook, which allows changing the reason.
This hook should be replaced in the long term, but for now it might be
sufficient to add it to the common UI logic and only run it for
non-file pages.
- The horrible $hasHistory hack. This is going to be a tad more
complicated because we need to remove it from WikiPage and
ContentHandler, and replace it with something else.
Bug: T288282
Change-Id: I965c32457b1426ece9781221a95337d295b9e1a2
filedeleteerror-short was repeated as an h2, but the parameters aren't
appropriate for prepareMessage() and filedeleteerror-short-old doesn't
exist. The message is used correctly in the following line.
Change-Id: I07481bd7d43e0596af3de183aa7814572805c8c2
Fix the last drifts between the two. Custom CSS IDs/names/classes in
FileDeleteForm were replaced with the base one, as I think it's better
to be consistent, and it wouldn't be trivial to allow changing those
values in a clean way. Question for reviewers: should this part be
announced on tech news in case somebody is using those values in a
script?
Move the file delete intro above the form, like we do for normal
deletion.
For normal deletion, use the content of the wpReason field as default
value for that field, not the result of merging the dropdown and the
"other" field, which doesn't seem correct (the file version was already
doing this).
Make the file deletion form use the title as token salt like the base
form -- it shouldn't make any difference AFAICS.
After this patch, it should be possible to make DeleteAction extend
FormAction with low effort.
Bug: T288282
Change-Id: I8b115ecb1c94af63d686a575b18362ac32105ae2
The two forms (article delete vs file delete) are basically identical,
but use different messages. Even if some file-specific messages might
possibly be deleted in favour of the base ones, it's still hard to
generate the form fields from a single place. Thus, this change
introduces a couple of methods to allow overriding the messages.
Bug: T288282
Change-Id: I1c26b24c16cb6ab6840edaca4bce0d582518b95d
Move all output-related code from Article to DeleteAction.
Article::doDelete is now deprecated, because there are some callers in
the wild, although I don't think any caller should need it.
Kill some ancient-PHP-style pass-by-refs that are useless and only make
the code more error-prone for both the caller and the callee.
Bug: T288282
Change-Id: Ic1de0ed8ebba15da5ed9f5cd11625017360a7672
Sync similar sections, factor out some common logic, fix some drifts
between the two.
Bug: T288282
Change-Id: I00db5118777bf744b924b8c3e3da53b1c5a35f5c
This is where the UI logic is supposed to live. The remaining methods in
FileDeleteForm will later be deprecated in favour of a dedicated command
object.
This patch tries to move the code to the new class with minimal changes,
with cleanup left to do for later.
Also change return typehints and docs for getFile(): WikiFilePage::loadFile()
is guaranteed to load a file. The "|bool" would confuse PHPStorm and
phan.
Note that FileDeleteForm is unused everywhere, except for some static
methods not touched by this patch.
Bug: T288282
Change-Id: I4fa1dfa096cd2ae7a58067764b12a275b1cce1d5
