Added:
- ContentHandlerFactory
Tests:
- PHPUnit
Changed
- Calls of changed and deprecated
- DI for some service/api
Deprecated:
- ContentHandler::* then similar to ContentHandlerFactory
- ContentHandler::getForTitle
- ContentHandler::$handlers
Bug: T235165
Change-Id: I59246938c7ad7b3e70e46c9e698708ef9bc672c6
Other protection warnings displayed by this function (via
LogEventsList::showLogExtract) are already styled that way
since 6fd6651c17.
Change-Id: Ibd1bb553ae012e55d8e3227ebc61b0d32c686e66
Some subclass is not calling ::setContextTitle(), but __METHOD__ is useless
here since it doesn't give us the name of the subclass, just 'EditPage'.
Use `get_class( $this )` instead.
Bug: T176526
Change-Id: I3652df98199c758e9ed8615263caf572e1d74695
Historically, if the content of a revision was missing (e.g. a bad entry
in the `text` table), EditPage would display an empty textarea.
Ia94521b7 accidentally broke that, causing an uncaught exception.
This patch restores the previous behavior, with the addition of a notice
at the top of the page that the content couldn't be loaded.
This also cleans up the missing section handling so it isn't so easily
confused with other failures (and also so it doesn't pass false to a
method declared as taking Content|null).
Bug: T237570
Change-Id: Ia70de11c2e4833b202fde3028a1a94dfc741f0a5
Accept these objects as params to the UserBlockedError constructor,
since they are used to make the block error message. Pass them from
SpecialPages, Actions and EditPage.
If a caller does not pass all of these params, get them from the
global context as before.
Bug: T234406
Change-Id: Ie8ef047d2710c523b67bfc54fa2ad70fc47c5236
This was previously hardcoded from three places: 1) Upon viewing EditPage,
2) Upon viewing SpecialCreateAccount, 3) For any url if the user is
logged-in (User::loadFromSession/isLoggedIn).
== User::loadFromSession
Performing cookie blocks from here created a circular dependency because
Block may need the user language for localisation, which is determined by
asking the User object. This was previously worked around by using a
DeferredUpdate (T180050, T226777). Moving this logic explicitly to the
end of the pre-send cycle in MediaWiki::preOutputCommit breaks the cycle.
This is also where other request-specific handling resides already.
== Limited effect on unregistered users
When an unregistered user performs an edit, and gets blocked,
the cookie block is not applied until they open built-in editor
or CreateAccount page. This makes it more likely for a user's
IP to change meanwhile. Either intentionally, or simply due to
IPs varying naturally (e.g. between mobile locations, or when
going on/off WiFi). By applying it throughout sessioned page
views for unregistered users, it is more likely to get set.
Similar to what was already done for logged-in users.
This commit also makes the intent of not caching EditPage and
SpecialCreateAccount explicit. This was previously implicit
through nothing having called setCdnMaxage() and/or due to
Session::persist being checked for by OutputPage::sendCacheControl.
Bug: T233594
Change-Id: Icf5a00f9b41d31bb6d4742c049feca0039d0c9d9
Phan can treat scalar types as non-interchangeable with
`scalar_implicit_cast` set to false. This patch fixes some of those
issues (which are in total >1000), namely the ones with alphabetic order
< includes/actions.
Change-Id: Ib1c6573ab899088bc319b9da9ceaffc850da3dbe
These were discovered by setting `null_casts_as_any_type` to true in
phan, and filtering by `PhanTypeMismatchReturnNullable`. Of course there
are others, some of which are false positives, but we cannot suppress
them now (or the UnusedSuppressionPlugin will complain).
Change-Id: Ia8443e575c22f47a6d8c63038f4e7ac36815fc27
If editing without JS, and clicking preview on action=edit
you will see a preview with a note at the top of the page.
McrUndoAction.php uses a close copy of the same code and will
be amended accordingly.
Currently this is using a class `.previewnote` and not the
standardised and semantic "warningbox".
The messages of the preview will now be warningbox's
- see screenshots for end result:
* https://phabricator.wikimedia.org/F30284946
* https://phabricator.wikimedia.org/F30284947
Bug: T232414
Change-Id: Ib678f03e908fa9dcd5af7632941475203478abf7
And also update approximated counts, which for the most part are lower
than reported (hooray!)
Bug: T231636
Depends-On: Ica50297ec7c71a81ba2204f9763499da925067bd
Change-Id: I78354bf5f0c831108c8f606e50c87cf6bc00d8bd
UnknownContentHandler can be configued to handle models that
belong to extensions that have been undeployed:
$wgContentHandlers['xyzzy'] = 'UnknownContentHandler';
This way, no errors will be thrown when trying to access
pages with the unsupported model. Instead, an error message is
shown, and editing is prevented.
This patch also improves handling of non-editable content in
EditPage and in DifferenceEngine.
Bug: T220608
Change-Id: Ia94521b786c0a5225a674e4dc3cb6761a723d75b
When the 'EditFilterMergedContent' hook set an erroneous status but
did not abort execution (hook function does not return false), we
always added a 'hookaborted' error to the status, regardless of what
was already set.
This mistake was not visible in the edit form, because error message
formatting was incorrectly done before that (which would actually emit
a different error if none was set).
However, the additional error code propagated to the API, where it was
emitted when using 'errorformat=html' (or any other format except the
default 'bc', which can only produce one error code/message).
This affects various extensions, including EventLogging, UploadWizard,
AbuseFilter (after I5424de38) and SpamBlacklist (after Id36aa6bd).
----
You can test this behavior with these two simple hooks:
// A: Set error status and error message
$wgHooks['EditFilterMergedContent'][] = function ( $context, $content, $status ) {
$status->fatal( 'test-message' );
};
// B: Set error status but no error message
$wgHooks['EditFilterMergedContent'][] = function ( $context, $content, $status ) {
$status->setOK( false );
};
Adding either of them to your LocalSettings will cause all edits to
fail as follows:
Before this patch:
| Error message in the UI | Error code in the API |
| Hook A | test-message | test-message, hookaborted |
| Hook B | internalerror_info | hookaborted |
After this patch:
| Error message in the UI | Error code in the API |
| Hook A | test-message | test-message |
| Hook B | hookaborted | hookaborted |
Bug: T231253
Change-Id: I106dbd3cbdbf7082b1d1f1c1106ece6b19c22a86
Move the cookie blocking logic into one place. Specifically, move
these methods to the BlockManager:
* User::trackBlockWithCookie
* DatabaseBlock::setCookie
* DatabaseBlock::clearCookie
* DatabaseBlock::getCookieValue
* DatabaseBlock::getIdFromCookieValue
* AbstractBlock::shouldTrackWithCookie
After this, BlockManager::trackBlockWithCookie should be called to
track a block, and BlockManager::clearBlockCookie should be called
to unset the cookie. The other methods in the above list are
helper methods that are made private or marked internal.
Also update places in core that call User::trackBlockWithCookie to
BlockManager::trackBlockWithCookie
Bug: T225141
Change-Id: I818962c6932c01c841a549a101637e00a7593e48
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
Was deprecated in 1.29 and EditPage::edit() was made available for
use and replacement of this ::submit().
Usage
=====
https://codesearch.wmflabs.org/search/?q=%5C-%5C%3Esubmit%5C(%5C)&i=nope&files=&repos=
The usage of ->submit() in the search link above are not for EditPage
but for other classes.
Change-Id: Ibd65965c785f84e9bda65cfaa2c491310cda8166
Keep Block as a deprecated class alias for DatabaseBlock.
Update calls to the Block constructor and Block static
methods from external classes.
Also update documentation in several places that refer to
blocks as Blocks.
Bug: T222737
Change-Id: I6d96b63ca0a84bee19486471e0a16a53a79d768a
T208768 introduced the PermissionManager service that can now be used
for page specific permission checks. This change replaces calls to
Title::userCan() with the new service in the EditPage class.
Bug: T220191
Change-Id: I835d68d6c47785cf35386bca0431907fee87f0c1
No code uses this parameter:
https://codesearch.wmflabs.org/search/?q=getEditToolbar
I suggest to skip any deprecation because of this.
It might be worth mentioning this in the release notes anyway, or is
it?
Change-Id: I5d47c22fa741df5f9c248e4e1bff2d6e97aca6a7
This is a clean up after collecting the necessary data related to
blocks and how often users see the block notices
See: https://phabricator.wikimedia.org/T189724
Bug: T214214
Depends-On: I047587c064e63e8bd4b933351edfec298f7c7956
Depends-On: I532a0cd95009109ba25caa8dd31badd5c1900da7
Change-Id: Icfa74ad6337c0a4f12ae24b43d36c0e3cb302a3b
