Allow specifying the title used for rendering error messages in
ApiErrorFormatter.
Then, specify one in ApiEditPage (and a few similar modules that deal
with single pages) once we've figured out which page is being edited.
Bug: T247661
Change-Id: Ic3d70efc23744ef6e90abc445f3babebf45c4697
Old PHP versions are fine doing a `switch` with anything, even
if the types don't match. This changed. More recent PHP versions
start to bring up notices and such when a `switch` accidentially
compares e.g. an object with an int.
Bug: T255177
Bug: T258790
Change-Id: Ib415bd2fb394b95b02737b6df50e4e1fbbc440d3
is not being changed.""
This reverts commit 149e99f072.
It's not necessary to change the constructor now, the module is already
using service locator to fetch RevisionLookup and ContentHandlerFactory.
The WatchedItemStore can also be gotten from there, voiding the need for
altering the constructor now. As Daniel said in T259960#6380471 dependency
injection for API modules is good but not urgent.
Bug: T261030
Bug: T264200
Change-Id: I16aa942cc800cd66a2cd538680a02b10cb0b1bfe
This reverts commit 07e547f47c.
Reason for revert: LiquidThreads extends the ApiEditPage class,
even though it shouldn't, and thus fails when the dependencies
are not injected.
Bug: T261030
Bug: T264200
Change-Id: Ib14f8a04bb6c723aa502a47ef9ccde6fe96a0ac7
This made it impossible to correctly undo changes if revision IDs are out of
order with respect to timestamps.
Removes block of code responsible for creating this bug, and updates tests to reflect the change
Bug: T190285
Change-Id: Id5837ed958023bdbf544ae0f79e2d5e05c94cc64
This trait is not needed in ApiBase and its presence here is
proving to be problematic. See I795db12.
In this patch, the trait usage (more precisely the 'use statement')
has been removed from ApiBase and accordingly the signatures of
ApiWatchlistTrait::getWatchlistValue() and ::setWatch() have been
altered to now require User object.
With these changes, the abstract getUser() method in the trait is no
longer needed, so it has been removed also.
All core usages of the affected functions are fixed in this patch.
The trait is used in only one extension according to codesearch tool,
the extension will be fixed in Ic22e163.
Bug: T262175
Bug: T248512
Follow-up: Ia18627b9824dca81f44f0571e8420d89b7626cf6
Change-Id: Idabcea71edfca9e7ed42000a258c99ff407873d4
Ensure the content we are trying to save and the base content have
identical content models before proceeding to save so as to forestall
Exception that may be thrown by ContentHandler if it founds they're not.
There are two cases where the models are allowed to differ: Edit that
undoes content model change or edit that's meant to explicitly change
the model. The logic for these is handled separately and may succeed
or fail, but exception will not be thrown.
Bug: T255700
Change-Id: I8782732bb0fc3059693cd7035b7ebb43fd71d333
This introduces an ApiWatchlistTrait that refactors out common code
across APIs that allow you to watch pages. Some methods have been
migrated from ApiBase and changed completely, but codesearch suggests
they aren't being used outside the API modules in this patch.
Bug: T248512
Bug: T248514
Change-Id: Ia18627b9824dca81f44f0571e8420d89b7626cf6
This is to fix issues with reverts being marked incorrectly,
especially when using the undoafter param which, until this patch,
wasn't really supported.
Honestly, EditPage is such a mess that I'm not sure if this is good
or not, but I did a lot of manual testing and it seems to work fine.
WikiPage::doEditContent() now checks whether the provided original
revision really has the same content as the new revision. This was
previously the task of callers, but that doesn't make much sense to
me because:
* This task would fall on EditPage otherwise and it should be more
focused on the UI side of things, without too much worrying about
backend details.
* This would require adding another parameter to WikiPage::
doEditContent(), $undoAfterId. It would be only useful for multiple-
revision undos that are not top revisions. In all other cases it
would be the same as $originalRevId.
* An extra sanity check before applying the value to the PageUpdater
won't hurt. Who knows what crazy ideas extensions might have.
The test cases are almost identical to those written for
McrUndoAction, so I decided to group them in a single file.
This should cover most undo cases.
Bug: T256915
Change-Id: I78641b3de0a012af932ea38265b695362f1f8491
Additionally, use Article::getPage() instead of relying on
Page interface proxy method in ApiEditPage, forgotten before
Bug: T239975
Change-Id: I01696a1b11b2ea5c3d94fcb9a42beea68eb7b804
The basic idea is: The sequence `$var ?? 'default'` either uses the
value from the variable (or array element) if available, or falls back
to the default value. The resulting value is then used in the if()
condition.
if ( $var ?? true ) means the variable should default to true, if not
set.
This is mostly a style change.
In ApiEditPage the $params are impossible to not be set.
Change-Id: Id67b81744fa21fe22a2d2377259e426aab67c479
This adds a baserevid parameter for detecting edit conflicts, as an
alternative to the less precise basetimestamp parameter. This is
introduced for parity with and use by the new REST api.
Bug: T230843
Bug: T34037
Change-Id: Id7565018f66860b5c2ba688777508db1b88700ae
Notably:
* In ApiManageTags, I used a switch instead of a dynamic function name,
so that the call graph will be correct.
* In ApiImageRotate, checkTitleUserPermissions() has always returned
void, this was an error introduced in 4e6810e4a2
Change-Id: Iea22616b8e7e2e0cc804619a54f8690898b2cb82
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
The 'editconflict' message is used by the normal edit form, and it
expects a parameter (page name), which was never passed.
'edit-conflict' should have been used instead.
This doesn't change the error code, which is mapped in ApiMessageTrait
and it already has a case for 'edit-conflict'/'editconflict'.
Change-Id: Ic95af27a67b95310b27ec344503d0a5cd88d79a2
Some of the errors are suppressed because they're phan false positives.
The idea behind this is that they'll be fixed in a future version of
phan, and we'll just have to remove the suppressions.
Note: I'm disabling UnusedPluginSuppression so that we can start suppressing
issues even if they're still disabled. The sniff should be re-enabled
as soon as we upgrade phan.
Bug: T231636
Change-Id: I0f7fa06a9e03fbb86c7a5eb6e50a850bb258a7f7
This reverts commit 01564dcbf7.
Reason for revert: I find the empty case far clearer as to intention than this change, and I doubt this is such a hot path that optimization should take precedence over clarity. If we really want to get rid of the empty case, I'd have structured it somewhat clearly as
if (
// always allow undo via api, T230702
!( $params['undo'] > 0 ) &&
// [something else here to explain this clause]
$contentHandler->supportsDirectApiEditing() === false
) {
But even that is IMO less clear. At the very least this seems to deserve more discussion.
Bug: T230702
Change-Id: Icc16250faad31abf7308c4af9be2e7658540346c
