If the page exists, it only checks edit rights, otherwise it
checks both edit and create rights.
This would only matter on wikis that have a non-default rights
configuration where there are users with undelete rights but a
restriction level enabled that prevents them from creating/editing
pages (or they otherwise aren't allowed to edit/create)
It should be noted that the error messages aren't used in the
normal UI currently, but they could be in the future, and
extensions could potentially be using them (The backend functions
return them, but the UI functions in Special:Undelete ignore
them)
Bug: T108138
Change-Id: I164b80534cf89e0afca264e9de07431484af8508
Directly redirecting based on a url paramter might potentially
be used in a phishing attack to confuse users.
Bug: T109140
Bug: T122209
Change-Id: I6c604439320fa876719933cc7f3a3ff04fb1a6ad
They were both doing the same thing, except that getOldestRevision()
checks the master if the revision is missing on the replica.
Change-Id: I21a118c6cd5c98fb846a0a2765574c0dbdbf7220
We want the page_timestamp index to be used in this case, but sometimes
the rev_timestamp is chosen which leads to bad performance.
Also update WikiPage::getOldestRevision() which uses the exact same query.
I'll implement one in terms of the other in a follow-up commit.
Bug: T159319
Change-Id: I7c5c0a9b1af99ce2b5f4bdcc99710d8400ca8bcf
Both Title::getPreviousRevisionID and Title::getNextRevisionID
have bad performance under certain versions of MySQL/MariaDB
when the page has many revisions (in the order of dozens of
thousands). This is good enough in most cases.
However, on a contributions slave, where it has an explicity
defined extended secondary key with the primary key, the
performance is really, really bad, performing a full table scan.
By ignoring the PRIMARY KEY index, contributions slaves go from the
worst case to the best case, while not affecting the plan of regular
slaves. It is believed that more recent versions of MySQL chose the
right indexes automatically, because they can use the extended primary
key automatically, without adding it explicitly. If that doesn't
happen, we can consider adding it explicitly to the regular slaves,
too.
In any case, not using the PRIMARY gives always a much better or at
least the same performance (this never causes a regression, unlike
FORCE'ing a specific index).
Bug: T159319
Change-Id: Ibb6e5240b87bd8e2d680fc4d58fcb3db1a4721cc
Title::loadRestrictions() returns restriction levels, not the
corresponding user rights. These are mostly identical except for the
backwards-compatibility levels "sysop" and "autoconfirmed".
For create protection it calls Title::getTitleProtection() to fetch
them, but Ic5026384 changed that to return rights. Split that function
into two, an internal method that returns restriction levels for
loadRestrictions() to call and the public method that converts levels
into rights.
Bug: T85108
Change-Id: I3ea4cb9c5e37b746402744dd7a883763ee07195a
I was bored. What? Don't look at me that way.
I mostly targetted mixed tabs and spaces, but others were not spared.
Note that some of the whitespace changes are inside HTML output,
extended regexps or SQL snippets.
Change-Id: Ie206cc946459f6befcfc2d520e35ad3ea3c0f1e0
It's unreasonable to expect newbies to know that "bug 12345" means "Task T14345"
except where it doesn't, so let's just standardise on the real numbers.
Change-Id: I6f59febaf8fc96e80f8cfc11f4356283f461142a
This patch adds an ug_expiry column to the user_groups table, a timestamp
giving a date when the user group expires. A new UserGroupMembership class,
based on the Block class, manages entries in this table.
When the expiry date passes, the row in user_groups is ignored, and will
eventually be purged from the DB when UserGroupMembership::insert is next
called. Old, expired user group memberships are not kept; instead, the log
entries are available to find the history of these memberships, similar
to the way it has always worked for blocks and protections.
Anyone getting user group info through the User object will get correct
information. However, code that reads the user_groups table directly will
now need to skip over rows with ug_expiry < wfTimestampNow(). See
UsersPager for an example of how to do this.
NULL is used to represent infinite (no) expiry, rather than a string
'infinity' or similar (except in the API). This allows existing user group
assignments and log entries, which are all infinite in duration, to be
treated the same as new, infinite-length memberships, without special
casing everything.
The whole thing is behind the temporary feature flag
$wgDisableUserGroupExpiry, in accordance with the WMF schema change policy.
The opportunity has been taken to refactor some static user-group-related
functions out of User into UserGroupMembership, and also to add a primary
key (ug_user, ug_group) to the user_groups table.
There are a few breaking changes:
- UserRightsProxy-like objects are now required to have a
getGroupMemberships() function.
- $user->mGroups (on a User object) is no longer present.
- Some protected functions in UsersPager are altered or removed.
- The UsersPagerDoBatchLookups hook (unused in any Wikimedia Git-hosted
extension) has a change of parameter.
Bug: T12493
Depends-On: Ia9616e1e35184fed9058d2d39afbe1038f56d7fa
Depends-On: I86eb1d5619347ce54a5f33a591417742ebe5d6f8
Change-Id: I93c955dc7a970f78e32aa503c01c67da30971d1a
Adds support for tagging log entries for the block, import,
managetags, and move API modules, using a 'tags' parameter.
Bug: T97720
Change-Id: I9d75d2cece317a7704c4bc6d734ad3cafe24544e
Title::moveSubpages() sometimes returns a single message-specifier array
and sometimes returns an array of such arrays. This is extremely
difficult for a caller to deal with. Since nothing in Gerrit other than
ApiMove calls this, let's just fix it.
Also, it seems that messages were never created for the errors returned
by this method. So let's create them.
Change-Id: I4e55483c4476a1bb96c87266a4661871776fbf9b
Most of these are simply changing annotations to reflect
reality. If a function can return false to indicate failure
the @return should indicate it.
Some are fixing preg_match calls, preg match returns 1, 0 or false,
but the functions all claim to return booleans.
This is far from all the incorrect return types in mediawiki, there
are around 250 detected by phan, but have to start somewhere.
Change-Id: I1bbdfee6190747bde460f8a7084212ccafe169ef
It looks like there is something missing after the last statement
Also remove some other empty lines at begin of functions, ifs or loops
while at these files
Change-Id: Ib00b5cfd31ca4dcd0c32ce33754d3c80bae70641
This is one of the top three DB queries showing up in xenon
reverse flamegraph profiling.
It works via a per-wiki check key that is bumped whenever
someone changes a .js or .css page on that wiki.
Change-Id: I73f419558864ba3403b4601a098f6aaf84a3e7c1
It is possible for page restrictions to be dependent upon the content
model a page. The best example of this is user JavaScript and CSS
subpages. This adds a Title::setContentModel() function which allows
mocking a Title's content model for the purpose of permission checks.
EditPage and Special:ChangeContentModel were updated to ensure the user
can edit the page with the newly proposed content model before making
the change.
Title::$mContentModel was made private to make sure nothing else mucks
around with it. There were no uses outside of Title anyways.
Bug: T145316
Change-Id: I28c46f408cadf65ed1868401cd00dc15e5acd2fe
Queries from parsing are the top use of selectRow() according
to reverse flame graphs on xenon. This does not bother with
pages in namespaces less likely to be included.
Change-Id: Ica5d6e52c830cd71effff21933b8c64691082c11
This is more consistent with LoadBalancer, modern, and inclusive
of master/master mysql, NDB cluster, and MariaDB galera cluster.
The old constant is an alias now.
Change-Id: I0b37299ecb439cc446ffbe8c341365d1eef45849
Does both Title and user related methods, so it catches things that only
call $wgUser->isAllowed( 'read' ), as well as giving a nicer error message
for things that use $title->userCan().
Otherwise, the user can still do stuff and read pages if they have an
ongoing session.
Issue reported by Multichill
Bug: T129738
Change-Id: Ic929a385fa81c27cbc6ac3a0862f51190d3ae993
Special:UserLogout should be whitelisted, if Special:UserLogin is whitelisted,
as otherwise the user is able to login, but not able to logout anymore (given,
that the sys-admin hasn't change the $wgWhitelistRead config variable).
Special:ChangePassword redirects to Special:ChangeCredentials. Instead of
adding this special page, it should be done explicitly in the
wiki configuration (LocalSettings.php). For this reason, the whitelist is
removed, too.
Change-Id: I271efb517bf0ec0022e6fe29673570ca08e8fe1a
This made sense back in php4, but has no useful effect anymore
with our minimum php version being 5.5. This also has the effect
of searching for 'function makeTitle' now actually finding something.
Change-Id: I0ea02a2e7dff285341b0e5b5b7773da78bfaaff3
* This puts the complex logic here after the commit step for
all DBs, making the main multi-DB transaction more likely
to be atomic.
* Made some cleanups to AtomicSectionUpdate and made it cancel
if the transaction is rolled back as it should.
* Also cleaned up some closures for PHP 5.4.
Change-Id: If2f7bb6b1ba6daf1cfdc934f27c32b0b10431a3d
Allow callers to get protocol-relative URLs by passing the
PROTO_RELATIVE constant. Since most callers don't pass in $proto, this
shouldn't change very much since the default of non-expanded is
effectively the same, but expanding to a protocol-relative URL when it
is not intended should still be safe.
A few callers that explicitly specified the default in core were also
updated.
Change-Id: I214f17aa6e8e30b647f21f0951fc3a15e87850c7
Since this updates happens post-send or via the job queue, the
page object will be for a non-existing or newer page/redirect.
Change-Id: I20b583948157dccceca6eb1fbd25121822bf1b2f
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
* Using addUpdate() makes sure purges are coalesced and
de-duplicated.
* Also removed incosistent $wgUseSquid checks. If CDN caching
is not used, then $wgSquidServers will just be empty anyway.
Bug: T119016
Change-Id: I8b448366f037f668385d252f9d68289b71d1a707
