This adds a high level regression test that ensures that xyz_from_namespace
fields are updated when a page is moved to another namespace.
Bug: T299275
Change-Id: I3f42802fab9c8b8747a587d7119731517be5518b
Add a new helper to MediaWikiIntegrationTestCase, since deleting pages
seems to be pretty common in tests.
Some calls to WikiPage::factory were also updated to use WikiPageFactory.
Change-Id: I5b5100273a00ac292a1900022ca79708fa254347
Before MovePageTest was skipped if the move was valid,
claiming we can't test actual moves. Now we can.
Additionally, use MediaTestTrait for file and repo
mocking.
Change-Id: Ie8a1edbdb2f22432919f03a60c2dacc5d4528615
Results in passing a user where previously the fallback
to $wgUser was being used, mostly in tests.
Bug: T255507
Change-Id: Iabe24315b23c0ad1272353186425e71974528d23
A new user right, `delete-redirect`, is added (not given to anyone
by default). At Special:MovePage, if attempting to move to a single
revision redirect that would otherwise be an invalid target (i.e.
doesn't point to the source page), the user is able to delete the
target.
Deletions are logged as `delete/delete_redir2`, and the move is
then logged normally as `move/move`, mirroring current delete and
move logging.
To allow for separate handling by Special:MovePage,
MovePage::isValidMove now returns a fatal status `redirectexists` if
the target isn't valid but passes Title::isSingleRevRedirect.
Otherwise, `articleexists` is returned (as previously). Other callers
that don't intend to treat single revision redirects differently
should treat `redirectexists` the same as `articleexists`.
Currently, this deletion (like normal delete and move) cannot be
done through the move api. Since the deletion is only valid when
moving a page, unlike for normal deletion, deleting redirects with
this right cannot be done via the delete api either.
Bug: T239277
Change-Id: I36c8df0a12d326ae07018046541bd00103936144
The name change happened some time ago, and I think its
about time to start using the name name!
(Done with a find and replace)
My personal motivation for doing this is that I have started
trying out vscode as an IDE for mediawiki development, and
right now it doesn't appear to handle php aliases very well
or at all.
Change-Id: I412235d91ae26e4c1c6a62e0dbb7e7cf3c5ed4a6
If there's no file to be moved (e.g. it's a redirect in the File
namespace), don't fail with an error about being unable to delete the
nonexistent file. Just let it work.
Bug: T249550
Change-Id: I605b0e4b39e7863bddbebf339994c819528e3a4c
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
This patch fixes the documentation of newFromText and makeTitleSafe to
no longer state incorrectly that any Title they return is guaranteed to
be valid. That has never been true.
It also makes canExist() checks a lot stricter, to match the assumptions
of current callers, namely that the title can exist as a wiki page.
Finally, it replaces several existing calls to isValid() with calls to
canExist().
Bug: T229705
Change-Id: I2a483136ec6acca49afb5eb32cb94616672b8fb2
This is just a shortcut for a commonly-used pattern, when you want to
create a mock that's never supposed to have methods called.
Change-Id: Ia7267e3d3108c1ff94485f7e44bf409808a762be
The expected values in many cases are silly, because our code is
currently silly and could use some refactoring. These are marked with
@todo. In one case the return value is even wrong (moving to an invalid
non-empty name is considered valid).
Change-Id: I9649a4de12bbcd6263c85de37d7b9365d9c0aeb4
This will help make MovePage more testable.
In the course of abstracting the logic out of ParserFactoryTest to
FactoryArgTestTrait so it could be used in MovePageFactoryTest, I made
them all unit tests instead of integration. This required some
modification to the Parser constructor so that it didn't access
MediaWikiServices unnecessarily.
Change-Id: Idaa1633f32dfedfa37516bb9180cfcfbe7ca31aa
If $wgContentHandlerUseDB is false and
$wgMultiContentRevisionSchemaMigrationStage is not SCHEMA_COMPAT_OLD,
RevisionStoreFactory::getRevisionStore() throws. This is coming up in
some seemingly unrelated code changes, perhaps due to access of stale
service objects, but I'm not sure because I can't reproduce locally. So
this is a shot in the dark to fix it.
Change-Id: Id29a62e1f537fa1b2016aac396773b728e238cda
moveSubpages wasn't officially deprecated at all before this release,
but there were no callers in codesearch outside core, so it should be
safe to hard-deprecate.
Bug: T208775
Change-Id: Icea9f1dc45d8bd8c96cc159d631f18c394aab4b7
So that using this hook it's possible to prevent the move, also
providing some more context.
Also, clean error message: instead of going with "you do not have
permission blah blah" for *every* kind of error, use it only when the
error is actually about permissions, and use a generic message
otherwise.
Bug: T208907
Change-Id: I4733724075b7514e9db59e7be772d9409aa9da87
