As part of refactoring the edit save logic, remove this public entrypoint - the
attemptSave() method is still available. Because the actual logic is still
needed by core, we move it to a new private method,
internalAttemptSavePrivate(), and call that from the deprecated
internalAttemptSave() method.
Bug: T157658
Change-Id: I79ccb85f645e15256c4b5867ef3997d10a611e53
Why:
- Edits made with a default request context with an anonymous user will
fail when temp accounts are enabled
What:
- Set a named user in the request context before making edits
Bug: T365669
Change-Id: Idb388a9c2fcbb77747fb8b3ebc37bf7eb201f80c
We renamed many classes to be namespaced, but the `@covers` and
`@coversDefaultClass` annotations weren't updated properly.
PHPUnit didn't support short cover annotations with `use` statements,
these didn't trigger any errors yet, because they are class alias.
This patch is populated by a modified version of PhpunitAnnotationsSniff.
Change-Id: I6c602290a30099239b17d2dc0d67b1488b4eaeeb
Just methods where adding "static" to the declaration was enough, I
didn't do anything with providers that used $this.
Initially by search and replace. There were many mistakes which I
found mostly by running the PHPStorm inspection which searches for
$this usage in a static method. Later I used the PHPStorm "make static"
action which avoids the more obvious mistakes.
Bug: T332865
Change-Id: I47ed6692945607dfa5c139d42edbd934fa4f3a36
Also moving TemplatesOnThisPageFormatter to the same namesapce as it's
only used by EditPage
Bug: T321882
Change-Id: Ibefc44eb64aedb430148b109090584c3e35794ab
All revision related classes are namespaced MediaWiki\Revision
instead of MediaWiki\Storage since 1.32. The old namespaced
class names are deprecated and only kept for backwards-compatibility.
Bug: T305784
Change-Id: I34e492d84d9fc4bc78481667202716d93b3c43cb
Results in passing a user where previously the fallback
to $wgUser was being used, mostly in tests.
Bug: T255507
Change-Id: Iabe24315b23c0ad1272353186425e71974528d23
Ugh, my mistake.
Also added a test that should cover this. It fails on the previous
version of code, succeeds after applying this patch.
Bug: T262463
Change-Id: Ifda30daadea5a908505423caaf818b9f88f989ad
This is a follow-up of T259014 which describes issues stemming from
users being able to mark arbitrary edits as undos (mitigation #3).
A "dirty" undo is when the user clicks the undo link and applies some
changes to page's content before saving. By doing so, the user can
set the edit's content to anything, while still marking the edit
with the mw-undo change tag and communicating to extensions that this
was an undo.
With this patch EditPage will only consider edits that had their
content provided by automatic conflict resolution as undos. Anything
other than that can't be reliably considered an undo.
THIS CHANGES THE BEHAVIOR OF EditPage IN A NOTICEABLE MANNER.
Most users should not notice anything different. In my opinion this
change makes EditPage's behavior more sensible and is justified.
Bug: T259014
Change-Id: I9279230303a01461039ae8a4641d9897ce194f73
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
