* Add missing "new" to methods that actually support it.
* Use more precise type hints in PHPDoc comments.
* Lowercase "string" and "array", they aren't objects.
* Drop a useless comment that only repeats the method name.
* Add some line breaks.
Change-Id: I2f50179eedffcb1809c46fa7ee1c062144a94ffe
The automatic patrolling on a already rolled rollback should be kept,
see bug 62157.
Bug: 62157
This reverts commit e6980c32f1.
Change-Id: I3b626452a0bab11e8b2a12545976cbd1df92ae1f
When a rollback will not create a new version, the rollback should not
be success normally. Raise the alreadyrolled error to indicate this
situation.
This can happen, when the same user already rolled back his edit in the
meantime.
Change-Id: I953ae1ca79abb37bc44f3f8244a42a34111e6ab8
Reset notification timestamp also for deleted pages on the watchlist,
this will give a empty notification on api's
prop=info&inprop=notificationtimestamp for the timestamp after visiting
a deleted page.
This also reset the remaining newtalk flags for anon user talks which
are effected by bug 14077.
Change-Id: Ibdb22ab1e0bea02b6ef730cd5737f91801b8d700
Adding the pr_id to log_search table and use a join to get the user,
timestamp and comment from the logging table. For logs without the pr_id
a placeholder text is shown.
The code for page protection is changed from a replace to delete/insert
to have for each pr_id a log_id and not reusing pr_ids which was used
for the first protection on a protection change.
The log_deleted field is checked to avoid showing revision deleted data
from the logging table.
This is a alternative patch for
Ie40057398a7829c698df3d68813006798a72dccb
and Iade82653999ca770586762b3c1383f73dfe3a5ee to avoid a schema change
on table page_restriction.
Idea by Aaron Schulz.
Change-Id: Ia0dc5895ec672896fe4b75c2e0f76da2474bd6e4
No uses found in core or Gerrit extensions.
* MediaWiki::articleFromTitle() (deprecated in 1.18)
* WikiPage::createUpdates() (deprecated in 1.18)
Change-Id: I689249b579ee89f883b97fdb4ac79fb3502c45dc
Due to bug 17259 (which is fixed in a better way in Id44d566a),
imagelinks only records the redirect and not the actual image used when
an image redirect is referenced. This causes various problems, such as
cascading protection not working through image redirects.
It makes more sense for imagelinks to work like tempaltelinks, recording
both so that things like cascading protection don't have to care about
image redirects explicitly.
Comparing imagelinks to templatelinks also reveals a few places
(WikiPage::doDeleteUpdates, WikiPage::doCascadeProtectionUpdates) that
should be triggering a LinksUpdate if the image links changed.
Bug: 23002
Bug: 23542
Bug: 26503
Change-Id: I64fe7d25646cae2c8213211893c6f821f3504dbf
Split the variable assignment and the return statement in two lines for
better readability.
When there was two return statements in one method the logic was swapped
to have only one return statement.
Change-Id: Id7a01b4a2df96036435f9e1a9be5678dd124b0af
No uses found in core of Gerrit extensions.
- Revision::revText() (deprecated in 1.17)
- SkinTemplate::jstext() (deprecated in 1.21)
- WikiPage::quickEdit() (deprecated in 1.18)
- WikiPage::useParserCache() (deprecated in 1.18)
- WikiPage::viewUpdates() (deprecated in 1.18)
Change-Id: I9eee23ea3ce381b6b8373da899287bcaea4cead4
If some caller passes null for the $serialization_format parameter,
they're going to break the in-memory caching of the prepared edit even
though it's likely that the format being used is the same as the format
being used by everything else.
It seems sensible to cache null as the default format for the content
object to avoid this.
Bug: 57026
Change-Id: I4ddcf6e388636e6a6397b664b8683ad774a09a04
Also remove wfTimestampNow because Database::timestamp will default to
now, when no param is given.
Change-Id: I0b065f4cdf67e1473548e641cf2864b4a2232ef8
This avoids broken characters for long comment.
The reason is shown on action=edit for unprivilieged users.
Change-Id: Ie8099f50628d55ff880760721169803ccbb3555c
In Wikibase, EntityContent is mutable and needs to clear
prepared edit before performing a save.
Follow-up to I2c34baa
Change-Id: I770bf2dc960c0a67a9b8315b7cdf24f3b89b6480
When a template is deleted, all pages transcluding it need to be
reparsed so that entries for transcluding pages in the various links
tables due to the transcluded content are properly removed.
Bug: 5382
Change-Id: I838b546caa3f5887e6bd312017c1fa71d3c3463a
== Prelude ==
wl_notificationtimestamp controls sending the user e-mail
notifications about changes to pages, as well as showing the "updated
since last visit" markers on history pages, recent changes and
watchlist.
== The bug ==
Previously, on every view of a page, the notification timestamp was
cleared, regardless of whether the user as actually viewing the latest
revision. When viewing a diff, however, the timestamp was cleared only
if one of the revisions being compared was the latest one of its page.
The same behavior applied to talk page message indicators (which are
actually stored sepately to cater to anonymous users).
This was inconsistent and surprising when one was attempting to, say,
go through the 50 new posts to a discussion page in a peacemeal
fashion.
== The fix ==
If the revision being viewed is the latest (or can't be determined),
the timestamp is cleared as previously, as this is necessary to
reenable e-mail notifications for given user and page.
If the revision isn't the latest, the timestamp is updated to
revision's timestamp plus one second. This uses up to two simple
(selectField) indexed queries per page view, only fired when we
do not already know we're looking at the latest version.
Talk page indicator is updated to point at the next revision after the
one being viewed, or cleared if viewing the latest revision. The
UserClearNewTalkNotification hook gained $oldid as the second argument
(a backwards-compatible change). In Skin, we no longer ignore the
indicator being present if we're viewing the talk page, as it might
still be valid.
== The bonus ==
Comments and formatting was updated in a few places, including
tables.sql and Wiki.php.
The following functions gained a second, optional $oldid parameter
(holy indirection, Batman!):
* WikiPage#doViewUpdates()
* User#clearNotification()
* WatchedItem#resetNotificationTimestamp()
DifferenceEngine gained a public method mapDiffPrevNext() used
to parse the ids from URL parameters like oldid=12345&diff=prev,
factored out of loadRevisionIds(). A bug where the NewDifferenceEngine
hook would not be called in some cases, dating back to its
introduction in r45518, was fixed in the process.
Bug: 41759
Change-Id: I4144ba1987b8d7a7e8b24f4f067eedac2ae44459
It's elitist mathematical jargon. In all cases dealt with here, it adds
no additional meaning compared to "if", beyond what was already obvious
from context. Thus, its only purpose is to smugly demonstrate that the
author attended their second-year mathematics classes, at the expense of
causing confusion for everyone who doesn't have such a background.
If you really think you need to convey extra information beyond what
"if" gives you, the English language contains plenty of devices for doing
so, without resorting to neologisms.
Change-Id: Iae21095d02ec2935c10e94f532235c2671c115b1
The ContentHandler branch inappropriately moved this essential
query to content-type-dependent code, despite the fact that revision
table cleanup needs to be done independently of content type. Before
r15707, the revision query was done immediately before the page query,
but it was moved down to allow it to be brought into the same
if (!$dbw->cascadingDeletes() ) block as the link updates. I have moved
it to immediately after the page delete, so that the rollback which has
since been added will not affect the expensive revision table query.
This should fix the database corruption we are seeing on some page
deletions (13 affected pages on enwiki, 14 on nlwiki, etc.)
Bug: 53687
Change-Id: I7a54c4416be07fb8cc7a5698e77927ccb24cbd6e
This causes problems where some pages can't be unprotected
as we still take the legacy field into account. See also
bug 33334.
Change-Id: Ibaec827289b1070ee110635d6c9d7b60e061384b
* Move cache time definition to happen before parse so it is less likely
to override the cache with a stale value and a high cache timestamp.
bug: 46014
Change-Id: I021d27885ac260d89232ff11ec3cccf976e44f0f
Split parts of doUpdateRestrictions() into several more concise functions.
The biggest drawback is increasing $dbw->encodeExpiry() calls times 3. This is
not much of a problem given that's a very inexpensive function and it is only
called very few times ($limit holds 2 values in current codebase)
Added $reason to the ProtectionForm::save hook, so that other code hooking into
and adding their own settings into page protection form can also process the
reason for the protection change.
Change-Id: I879290ed83e4e47e9561d4c352fbd50c07d7e18a
Main reason is so internal code does not have to recreate the database query
each time. This will also be useful for extensions.
Change-Id: Ia80c051ff0691087564710f2864ed617d5b9ee96
* The "autoconfirmed" right is now only used to determine "newbie"
status for the purpose of rate limiting, so I updated the
"right-autoconfirmed" message accordingly.
* The "protect" right now does not allow the user to edit protected
pages, so I updated the "right-protect" message accordingly.
* Also removed outdated portions of code comments referring to the
now-fixed bug identified in r31462; the 'protect' right is now
necessary to edit any directly or indirectly cascade-protected
page.
Follows-up I6bf650a3fbdab8589ae6945c8c916eafd949e41c.
Change-Id: Ia3cc487dd0ad168001a076ebd612eb64764e92ef
Title::getRestrictions can return "sysop", which will not match if
replaced out of $cascadingRestrictionLevels but not $editrestriction,
making it impossible to cascade protect a page with the default value
of $wgCascadingRestrictionLevels.
Follows-up I6bf650a3fbdab8589ae6945c8c916eafd949e41c.
Change-Id: Ie7183ed9509ea9c65a7197fc9cead6c8423b852e
In practice, this should not currently be happening: null revision can not be
created if no previous revision exists, which should not be the case where we
call the function in doUpdateRestrictions. However, since newNullRevision can
potentially return null (it's documented that way, perhaps some day in the
future, additional code paths can lead to null), we should check for it.
Also: after completing the restriction updates, the null revision is passed
along to a hook, which is documented[1] to get a Revision object. Right now,
in theory, this could be incorrect.
1: https://www.mediawiki.org/wiki/Manual:Hooks/NewRevisionFromEditComplete
Change-Id: I89b0be823d9933d557470005c390a9102f931684
