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
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
These behave the same as newFromLinkTarget/TitleValue, but accept null
as well (and then just return null). This makes things much easier when
converting code from using Title to LinkTarget, because you can wrap in
castFromLinkTarget without adding null checks.
Change-Id: Id61f91d40b81ad226532917c43e51f0b69af712c
The method could not be used in session-less endpoints. This was
worked around once in the Startup module.
I plan to use this method in an extension module as well,
and would prefer not to duplicate core's logic for determining
the main page, outside this repository.
As general dependency-injection pattern, it seems desirable
to allow injecting a MessageLocalizer here.
Change-Id: I76cd02b2f489882e9404b93270f76aad9f0a4d9d
First iteration of adding a PermissionManager service as a replacement
for Title::userCan and User::isBlockedFrom methods.
- Created PermissionManager service
- Migrated Title::userCan to PermissionManager::userCan and deprecated the first
- Migrated Title::quickUserCan to PermissionManager::quickUserCan and deprecated the first
- Migrated User::isBlockedFrom to PermissionManager::isBlockedFrom and deprecated the first
Same for User::isBlockedFrom and PermissionManager::isBlockedFrom - the
$user parameter is now required so the declaration is changed from
isBlockedFrom( $title, ... ) to isBlockedFrom( $user, $title, .. ) which
means before User::isBlockedFrom removal all calls to it need to be updated.
Added PermissionManagerTest, it copies TitlePermissionTest but uses
PermissionManager instance instead of Title methods, this way keeping both tests
in place, we can ensure that nothing was broken and both are in working state
during the deprecation phase.
Bug: T208768
Change-Id: I94479b44afb3068695f8e327b46bda38e44e691f
The "new" part of some of the newXXX pseudo-constructors
in the Title class is a lie: these methods do not always
return a new instance. This patch ensures that this fact is
documented, and we have a safe way to get a fresh Title
from a LinkTarget.
Needed by I94479b44afb30
Change-Id: I4d561ef7d7447d3d6e35079cf656bd564882d25e
