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
This also includes the integration test from SemanticMediaWiki that
caught this issue.
Bug: T74870
Change-Id: I699e14958ee36ec5e86278e5dc0caed2a015d9af
