Bad redirects in the database led to fatal errors when attempting to
resolve the redirect when visiting the page. This patch does three
things to address this:
* change Title::isValidRedirectTarget to actually check whether the
target is a valid title.
* change WikiPage::recorddRedirectEntry to reject invalid redirect
targets
* change WikiPage::getRedirectURL to ignore invalid redirect target
that may be present in the database.
Bug: T278367
Change-Id: Ib17ebfb99fa17b846302438c675a968a1ec0f488
This patch hard-deprecates the following methods,
that are overdue for hard deprecation:
- ::getPreviousRevisionID
- ::getNextRevisionID
- ::getFirstRevision
- ::getEarliestRevTime
Also, it removes the following methods:
- ::countRevisionsBetween
- ::getAuthorsBetween
Bug: T274151
Change-Id: If022b907652efdad84180476649a612059c6ef18
This reverts commit 36f1adf670.
This has seemingly broken FlaggedRevs and thus a bunch of repos.
Bug: T272170
Change-Id: I26c6fd656c75a6b209fb17965dc9109edf68642b
This allows Title and WikiPage objects to be compared with PageIdentity
and LinkTarget instances consistently.
Change-Id: I1bbd15d17d046359393ecfc1acd2778273260a95
PageIdentity is intended as a lightweight alternative to Title,
similar to LinkTarget, but providing a page ID. It follows the precedent
of UserIdentity.
Bug: T208776
Change-Id: Iaed4871e0d32c67d4fb13e487625527f6a21e9c5
* parent::setUp() should be first, and ::tearDown()
should be last
* Move tests that directly extend PHPUnit\Framework\TestCase
to /unit
Change-Id: I1172855c58f4f52a8f624e6d596ec43beb8c93ff
The InterwikiLoadPrefix hook isn't compatible with Parsoid, as it is
unidirectional and doesn't support enumerating all valid prefixes
(T270444). Set/reset $wgInterwikiCache to mock the interwiki table
for parserTests and other unit tests instead.
This is a soft deprecation, as the used-in-production
Extension:Interwiki still uses InterwikiLoadPrefix, although not in a
way that would break Parsoid (since $wgInterwikiCache is set in
production).
Bug: T270444
Change-Id: If2507017c99c4ee42c104a0890bc45a84d7239d5
Title::userCan, ::quickUserCan, and ::getUserPermissionsErrors, hard deprecated in 1.35
Bug: T246138
Change-Id: Iee990a16c15bd827cf631fb5ff683367082d2ebe
This is for consistency with the previous behaviour.
Follow-up: I3d8c6f6ffc4234ac938a39f5cc55691d62e1d7ac
Bug: T256922
Change-Id: I0928f85c862d3b2baf49317a206ca140a1ab3c16
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
This ensures that getBaseText and getRootText always
return a valid title, even for degenerate cases like "/" or
"//foo//bar//baz//".
Bug: T229443
Change-Id: I3d8c6f6ffc4234ac938a39f5cc55691d62e1d7ac
* Move the Title::getCdnUrls() logic to the new HtmlCacheUpdater service.
* Introduce a runtime option to decide whether this is for a direct
revision or a cascading LinksUpdate.
Bug: T250261
Change-Id: I514b9052761e0d949234996e97fdef255582df86
* This currently produced urls like "index.php?title=…&<langcode>"
which don't actually do anything. The proper syntax is "variant=langcode".
These danging variants were nothing but PURGE noise, as random
as e.g. purging a url like "…&rand123" would have been.
* Regardless of all this, page views with a language variant don't
actually emit a public cache header right now in MediaWiki, which
means there is not actually anything to purge from the CDN in the first
place. Revisiting whether we want to start caching them (and then
where/when to purge them) is subject of T250511, which can happen
after this logic is moved to the HtmlCacheUpdater service.
Bug: T250511
Bug: T250261
Change-Id: I497cb2be2e9f16156cf02afeb437bdca1b2cc1fd
The method was soft-deprecated in 1.34. It's not used in any WMF
installed extensions or the tarball, so it can be hard deprecated.
Bug: T220191
Change-Id: I2f48d62a8dd3592918a6197168d31a1e08bd2a3e
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
assertEquals( false, … ) still succeeds when the actual value is 0, null,
an empty string, even an empty array. All these should be reported as a
failure, I would argue.
Note this patch previously also touched assertSame( false ). I reverted
these. The only benefit would have been consistency within this codebase,
but there is no strict reason to prefer one over the other. assertFalse()
and assertSame( false ) are functionally identical.
Change-Id: Ic5f1c7d504e7249002d3184520012e03313137b4
These callers just need to load some data from DB_MASTER.
Subsequent code needing that latest title data should also use the
required flags, rather than relying on flakey global cache state.
Change-Id: I53248ea4b5bf1cd953f956c41b8244831ec5ef04
NamespaceInfo::getTalkPage will throw an exception for these.
With this patch, Title::getTalkPage() will be reverted to the old
behavior of returning an incorrect meaningless value. Logging has been
added to identify code paths that trigger this behavior.
This patch should be undone once all such code paths have been found and
fixed.
Bug: T227817
Change-Id: I4727c7bb54d6f712ddcab05ef278a08d728f5726
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
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
Otherwise, Title::makeTitleSafe() will return null, which
breaks the assumption that Title::makeTitleSafe() always
returns something meaningful for strings
returned by Title::getRootText().
Bug: T227816
Change-Id: If79a12bb8d23f1eafc10017d56c62566f39347ad
This issue was discovered while investigating T227700, and added some
confusion. This patch is necessary for Special:MyLanguage to behave
correctly in all cases, but it's not necessary for fixing the primary
critical problem.
Bug: T227700
Change-Id: Ib4cbeec47a877c473cbd501cc964cc66d169b99e
This causes Title::getTalkPage and NamespaceInfo::getTitle() to throw
an MWException when called on a LinkTarget that is an interwiki link
or a relative section link. These methods were already throwing
MWException when called on a link to a Special page.
Bug: T224814
Change-Id: I525c186a5b8b8fc22bca195da48afead3bfbd402
Since getBaseText() and getRootText() may return text with trailing
whitespace, getBaseTitle and getRootTitle must use makeTitleSafe instead
of makeTitle.
Bug: T225585
Change-Id: Id92df552f05e6a9ed7c9259a8779fa94c3587a3e
Was reverted by I549810a4cd2e424cc4a438887d2f24614a24cc00 due to
T224607.
Original change by Vedmaka Wakalaka was
Ia0d840b772ea5f20c9594ce151cc57adc270e48b.
Original commit message:
The following methods should are factored out of the User class into PermissionManager,
leaving only deprecated stubs:
- User::isAllowed -> PermissionManager::userHasRight
- User::getRights -> PermissionManager::getUserPermissions
- User::groupHasPermission -> PermissionManager::groupHasPermission
- User::getGroupPermissions -> PermissionManager::getGroupPermissions
-User::getGroupsWithPermission -> PermissionManager::getGroupsWithPermission
- User::groupHasPermission -> PermissionManager::groupHasPermission
- User::isEveryoneAllowed -> PermissionManager::isEveryoneAllowed
- User::getAllRights -> PermissionManager::getAllPermissions
Depends-On: I7909e9bd6bbfbd708c0a00b861a9b22a38c6665d
Bug: T218558
Bug: T223294
Change-Id: I8899240378f636ea70f447616710516c0a3c5c31
