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
Bug 50785: don't queue refreshLinks jobs on null edit or API
action=purge forcelinkupdate=1, since these actions are commonly
performed in order to clear the cache of a single page, and queueing
millions of jobs is not the response the user usually expects.
Change-Id: I2dbb5d21fa6b876adefd6bcfc93a83c5904d8d13
It has long been recognized that using the 'protect' right to control
the ability to edit sysop-protected pages is troublesome. r31247 fixed
this by adding an 'editprotected' right, but for some reason in r32164
this was changed to bypass protection completely instead of fixing the
bug identified in r31462.
This patch goes back to do it the right way: editprotected no longer
bypasses all protection, and it is used instead of 'protect' for
controlling access to sysop-protected pages. For good measure, the same
is done with autoconfirmed protection (semiprotection): a new
editsemiprotected right is created instead of overloading the
existing autoconfirmed right.
This also fixes bug 27152 by making editprotected no longer special.
Bug: 13137
Bug: 27152
Change-Id: I6bf650a3fbdab8589ae6945c8c916eafd949e41c
This is still less than ideal, but at least consolidates the
logic so we can later implement more content-specific handling.
Change-Id: Ic24a7ea2818f6eeb67453877dc5a31f110541ecf
Right now, if you delete a page then you end up with a stale
entry in the search index, this affects all core SQL-based
searches.
For extensions, this means they no longer have to implement
something like ArticleDelete, they can just add the delete()
method to their SearchEngine subclass.
Change-Id: I9d8a9878aeebc53f453ab1cbacc03fe73fcca949
* Also made it avoid inserting aggregate rows on membership
decrement if there was no prior row aggregate row.
Change-Id: I7e6d07e42cc06cedbd9d10ed9f276f20636dc222
Removed actions that should not be in Title::invalidateCache,
specifically the clearing of the InfoAction cache, and added
those actions to their appropriate locations.
Added a new method InfoAction::invalidateCache that clears the
cache for a given title.
Bug: 46816
Change-Id: Ic12c66446c0d71f567dceb5d4630382ff41ad8bf
A page can only be protected with cascading protection if the
requested restriction level is included in this array.
This replaces previously hard-coded values of 'sysop' and 'protect'.
This is necessary, because if any protection could be
cascading, users could who cannot normally protect pages could
"protect" them by transcluding them on protected pages they are
allowed to edit.
Bug: 47617
Change-Id: I5f8bcc899b46d466161894606cd27bf3b8624bd0
This hook allows extensions to disable or modify the new messages
alert ('orange bar of doom') while still allowing the user_newtalk
table to be updated.
The wgUserNewMsgRevisionId JS global allows gadgets and extensions
to create their own new message alerts on the client side.
I also threw in a few comment updates for good measure!
See also Echo change I3f35a56b which utilizes this.
Bug: 47962
Change-Id: I2105bdd2bcd5b27f6f36ec8d8fa7fa99d60a2d82
The recipient is the user who's talk page was edited. Extensions may
want to send or not send the notification based on some aspect of the
user, for example a preference.
Bug: 46550
Change-Id: Ifc8fbaf8fdc96f9c18c2a889d2e854e49b3a7010
And added/removed spaces around some other tokens,
like +, -, *, /, <, >, =, !
Fixed windows newline style
Change-Id: I0b9c8c408f3f6bfc0d685a074d7ec468fb848fc8
* Removed spaces around array index
* Removed double spaces or added spaces to begin or end of function
calls, method signature, conditions or foreachs
* Added braces to one-line ifs
* Changed multi line conditions to one line conditions
* Realigned some arrays
Change-Id: Ia04d2a99d663b07101013c2d53b3b2e872fd9cc3
