This makes the use of the global InterwikiLookup singleton more explicit
in the Title class. It does not remove the strong binding between Title
and InterwikiLookup.
Change-Id: Iaeb7c418af17fe19f170487f5364040da6052699
This should help reduce contention in some cases.
If too many rows are expired, subsequent updates will
clear them out.
Bug: T135470
Change-Id: Iada496d0db9b00e77037320d7c65124a8c8f68c0
If a new revision has been inserted (e.g. with updateRevisionOn),
the content model may have changed. This happens with e.g. undeletion.
Bug: T122262
Change-Id: Ia0ed86a9c24809256215418673e9ee8e263d1349
If $query doesn't match the regex, there's no point in unstubbing $wgLang if
that's what happens to be the page language. This also avoids it blowing up if
$wgLang isn't usable due to MW_NO_SESSION.
Bug: T135389
Change-Id: I9a6779c4cc887205215a815db3a765c35f060c42
This doesn't make sense because 'editcascadeprotected'
effectively gives you 'protect' rights.
Furthermore, no actual usecase was provided except for a testwiki.
This reverts commit da3464bada.
Change-Id: I655c1af8f418369c9551db86f24fb6b66c25afdd
Currently, both permissions are summarised in the protect permission. This is
unadvantageous for wikis that want to split this permission, for example for the
main page: They don't want protection changes by non-sysop users there, but on
transcluded pages some less privileged users are allowed to edit. Currently,
it is impossible to divide these permissions in a clean way (they can add a hack
depnding on action parameter in LocalSettings.php right now). Furthermore, an
additional permission is no pain, because by default it is handled the same as
protect until now.
Note that for sakes of backwards compability I decided to handle editcascadeprotected
as a subset of protect instead of removing all permissions to edit cascadeprotected
pages (and change the cascade protection state of a page) for users who only have got
the protect permission. Furthermore a different model would raise some strange questions
about the behaivour of the protection form for users with protect, but no editcascadeprotected.
Bug: T101309
Change-Id: I0734d6c26e75d7d7c01cf9750ad0315dd2c85bef
Title::newFromLinkTarget() will now take the interwiki component from
the LinkTarget object, and Title::getTitleValue() will pass on the
interwiki part if there is one.
Follows-up 9b1f8b4ca3.
Change-Id: If1fecc9d71e58c476d6cebe6164cdc95f183048d
The createFragmentTarget function allows for switching the fragment on a
target in an easier way. TitleValue already had a now-renamed
createFragmentTitle function (no uses outside of tests), and an
implementation was added for Title.
This will also help with reducing the amount of public usage of
Title::setFragment(), which is deprecated.
Change-Id: I1e8ba2f85e748b1b4394fb2f2a1ccce69cf6e3c5
Every single caller of Title::newFromLinkTarget() already special cases
when the LinkTarget object is already a Title, so move that logic into
one function.
Change-Id: Iba5432ae01c87850e5b34893092427c5b1629188
Follows-up 448c7ea03a, 372ded2f, 156bcbec, Ic85d27d.
* Removes the logger added in 448c7ea03a.
* Turn the warning into an exception. This was difficult previously
because non-string values were common. However most of them were
all null. Cases of other primitives (type object already throws)
have been fixed.
Bug: T76305
Change-Id: I62fe3f700d94168ca35c833410171b1c48e6c4f3
This also removes assumptions that when a page
in one Namespace should be watched / removed
that the page in the talk / subject ns for the
page should have the same action applied
This should maintain all backward compatability
for the WatchedItem class
This also includes tests written by:
- WMDE-leszek
- Addshore
Bug: T127956
Change-Id: Iad9abafe4417bb479151a3bfbee6e1c78a3afe3c
If a page language in database is set then use the current preferred variant
of this language.
Bug: T117667
Change-Id: Idfe1165346ae0068a4b73de441dc9dfa107b8e8b
If the Title object isn't the title of the current viewed WikiPage, the page_lang
field of the database isn't requested. This results in the problem, that
Title::getPageLanguage() always returns the default content language, even if
the page language is different (changed with Special:PageLanguage, if
wgPageLanguageUseDB is true). That is problematic for the Translate extension,
which relies on the correct page language.
This change makes sure, that getPageLanguage() always return the correct page
language. If the page language isn't loaded already, Title::getPageLanguage()
now does a database lookup (if $wgPageLanguageUseDB is true) to get the correct
page language. It will use LinkCache for the page_lang field.
Bug: T121666
Change-Id: I0ae5ea39f7a124ed427ca5dfb26c1a116b27a94e
With the roll-out of the Gadget namespace, these are going to be
especially misleading and likely to cause bugs.
Change-Id: I61f1f56762711fab173bbc54d110a7c48604d464
This will always return a MediaWikiTitleCodec object.
This is called in Title::secureAndSplit which expects
the method splitTitleString which is only in this
implementation and not the interface
Change-Id: Ibb6cdcf7deb6c1080e320379aa58981e9935ca33
To be used by things that do not care if they are
passed a Title or TitleValue so long as it has a
dbkey, namespace, possible fragment and text
Example uses include:
LinkBatch::addObj
MediaWikiPageLinkRenderer methods
MediaWikiTitleCodec methods
PageLinkRenderer methods
TitleFormatter methods
Change-Id: I2aa1a82129bb01155924a8e6a403c7a47391432f
This is the cause of the T76305 debug log entries relating to SpecialExport
and Echo.
Bug: T76305
Bug: T116034
Change-Id: I64d629d31be79c4b4702a4298bce68fd544df6e8
getPageLanguage() from ContentHandler already returns a Language object.
wfGetLangObj is not necessary.
Change-Id: I556236419e445ce549598dd1752b29f619b0ca3c
