getTimestamp() returns the timestamp of the revision, and as far as I
can tell that's null here, presumably because we haven't saved the
content and thus there is no revision. getCacheTime() returns the time
when the page was parsed, which is probably what we want.
Change-Id: I7dc446800656236f6ecc872a65e620881e434c54
If we were rate-limited, we don't store a new hash, so we shouldn't
return a new one. If we received a hash from the client, however, that
should still be valid, so we can return it.
Change-Id: Ifc37ae044172b8838fee15d539b076a0d0f02f22
It doesn't make sense to submit both stashedtexthash and text, so
requireOnlyOneParameter() is correct. This simplifies the code and
gives a more helpful error message. (Previously if both parameters were
passed, we would ignore text unless stashedtexthash was empty, in which
case we would ignore it.)
Change-Id: I306b15eefb6fd4379a3eed88d84113c2e43c4a95
Storing the user name or IP in every row in large tables like revision
and logging takes up space and makes operations on these tables slower.
This patch begins the process of moving those into one "actor" table
which other tables can reference with a single integer field.
A subsequent patch will remove the old columns.
Bug: T167246
Depends-On: I9293fd6e0f958d87e52965de925046f1bb8f8a50
Change-Id: I8d825eb02c69cc66d90bd41325133fd3f99f0226
The makeKey() method should do escaping and shortening, but it
is safest and clearer to not rely on that.
Change-Id: Ia4a95e0bb12074d141ddcca2089b920403cab100
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
API warnings and error messages are currently hard-coded English
strings. This patch changes that.
With a few exceptions, this patch should be compatible with non-updated
extensions:
* The change to ApiBase::$messageMap will blow up anything trying to
mess with it.
* The changes to the 'ApiCheckCanExecute' hook will cause a wrong
(probably unparsed) error message to be emitted for extensions not
already using an ApiMessage. Unless they're currently broken like
Wikibase.
Bug: T37074
Bug: T47843
Depends-On: Ia2b66b57cd4eaddc30b3ffdd7b97d6ca3e02d898
Depends-On: I2e1bb975bb0045476c03ebe6cdec00259bae22ec
Depends-On: I53987bf87c48f6c00deec17a8e957d24fcc3eaa6
Depends-On: Ibf93a459eb62d30f7c70d20e91ec9faeb80d10ed
Depends-On: I3cf889811f44a15935e454dd42f081164d4a098c
Depends-On: Ieae527de86735ddcba34724730e8730fb277b99b
Depends-On: I535344c29d51521147c2a26c341dae38cec3e931
Change-Id: Iae0e2ce3bd42dd4776a9779664086119ac188412
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
* Send stash requests when the summary changes, so that things like
AbuseFilter caching have a higher hit rate.
* Make the backend API skip parsing if a fresh cache is already present.
This makes requests for summary-only changes much faster and more likely
to finish in time.
* Avoid sending the full text if only the summary changed since the
last successful stash. This works via an optional stashedtexthash
parameter to the API.
* Also always apply the lock in parseAndStash(), even for VE.
Change-Id: I9bfd74cf05411853b675c6f54ff5d8934bcfc54c
During both the edit stash and first parse in on page save,
guess what the rev_id will be and use that instead of null.
Only reparse if it turns out to be wrong. This avoids extra
parsing on wikis that have low-medium traffic, and does not
cost much. The parsing that can be avoided is:
a) in doEditContent() by using the stash
b) in doEditUpdates() by using the doEditContent() result,
whether that was able to use the stash or not itself
Also improved the parse operation logging in save paths.
Bug: T137900
Change-Id: Ic6faae70a78b4e223e4d3585cefd482c0fa00677
At least avoid the first parse in doEditContent()/filters which
never has the revision set either. The second parse cannot be
avoided in doEditUpdates() however.
Bug: T136678
Change-Id: I12d2c3bbe1b21ad2ed9a484745d976ad62475e0d
* Users are likely to save after they inspect and review their changes.
The buttons to do so are also located below the edit summary box.
* This obsoletes the backend stashing on preview. Most of those parses
would have been useless due to being per-section only. Also, some
extensions like the Graph extension disable stashing for "preview"
output anyway. Simplify the code by removing that method.
Bug: T136678
Change-Id: Ied77bdbd191dd9267d4295b0fa7b942f65b062db
Per https://grafana.wikimedia.org/dashboard/db/edit-stash, the
proven_* cases are almost never hit. Simplify the code to avoid
complexity and slow link table queries.
Change-Id: I3f8bd79a80ddb26c6188b1a301c08766e38f6ad4
Only factor in the user ID/name/sig instead of anything that
might happen to touch the user row.
Bug: T136678
Change-Id: I004790a017c68cfcff6729f6fbfd0f79b6904c20
This still handles users editing inclusions themselves, but is
more relaxed in terms of edits by other users to the inclusions.
Bug: T134620
Change-Id: I6c0d189957481dfb6da0e73581b1d5b69fd3a352
* The wrong time method was used, and it also was not set.
* Bumped the threshold a bit while at it, which was basically
0-5 minutes before.
Bug: T133332
Change-Id: Ide3e66f551aa6e50410c562e5c917141d59b7f64
Instead of just counting cache hits and misses, segment the counts by reason,
so we can differentiate (for example) timestamp-based cache hits from
staleness-check-survivor cache hits. I want this data so I can determine
whether increasing the cutoff for timestamp-based hits from 3 to 5 seconds has
a substantial enough impact to warrant the slightly weaker consistency.
Also changed 'cache-hit' to 'cache_hit'. MediaWiki normalizes the dash to an
underscore anyway, but the normalization is there for dynamically-constructed
key names (or name segments). In the case of hard-coded values, it is desirable
for the code to be as close as possible to the final form of the metric name,
to simplify metric lookup.
Change-Id: I0cd61da9746e3ca3695e23200f698b8b1371798c
Convert the wfDebugLog calls in ApiStashEdit to direct use of the PSR-3
logging layer and add severity information for each message.
Change-Id: Ic91e89ceee405a1d22e5e3c461ad37795cae4a6f
* These are hit when the stashed edit is several seconds
old. The old code was not using makeList() correctly.
Bug: T105597
Change-Id: I265307715996c50d819915a55ea34bbc0ed6c5c9
