On WMF wikis, the partitioning of the revision table on the
'contributions' replicas makes the query here perform really poorly.
Specify 'api' as a hack for now to avoid those replicas.
This query happens once per day per wiki, plus when someone edits the
MediaWiki namespace, so it shouldn't be much additional load.
Bug: T164666
Change-Id: I5ae74d1702144f6475e9cfb13effc43389d66233
This will allow CSS to target just the parser output, without also
accidentally targeting the edit form, diff tables, and so on.
Bug: T37247
Change-Id: If4eb5bf71f94fa366ec4eddb6964e8f4df6b824a
Depends-On: I330c6aa4aaee045614b1801ed34bc9e03be69650
Depends-On: I52a518fa44e017841fe78474012cd69823e0a41d
System messages may take parameters from untrusted sources. This
may include taking parameters from urls given by unauthenticated
users even if the wiki is a read-only wiki. Allowing <html> tags
in such a context seems like an accident waiting to happen.
Bug: T156184
Change-Id: I661f482986d319cf41da1d3e7b20a0f028a42e90
Only 1 message typically changed per run, so for wikis using
external storage and with many customized messages, this can
make rebuilds considerably faster.
Bug: T158084
Change-Id: Ib668e69a207e3fbeb7871f2f6a102ff1af567368
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
The member variable is needed in the next lines, which previously
just used the array with "LATEST" set and would be seen as invalid
and discarded next time.
Bug: T157033
Change-Id: I5b84b1ae4a9c7b710ee452c61d7d9d6076ec9e6a
* This fixes keys based on some sort of change log.
Updates are wrapped in a mutex and keep track of the
last known good position.
* Make WANObjectReapUpdate class that cleans up title
related keys using the recentchanges table. This triggers
as a deferred updates on RC view.
Change-Id: I7f14b9ca2533032147e62b1a3cc004a23da86579
Do the process cache update immediately (as before) but push
the shared cache updates to a deferred update. This update
will thus start with a clear transaction snapshot, so it can
acquire the lock before the first SELECT as is proper.
Also added some missing method visibilities.
Bug: T144952
Change-Id: I462554b300d4688b09ab80cd1bb8a4340ffaa786
So that extensions like MessageCommons can try to use this (and
$wgLanguageCode) instead of $wgLang->getCode()/$wgContLang->getCode(), as
the latter ones cause fatals and recursion, at least with the Gadgets
extension also enabled at the same time.
Change-Id: If71fe1ded26c7a1c771128397783783ad5715b00
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
Re-submission of 9339a08b7.
* Increase time range for getValidationHash() using "latest" values.
The lower value ran the risk of regenerating from slaves and ending
up with *older* data than what was there.
* Avoid cache set() calls in replace() unless the lock was acquired.
Use delete() instead in that case, which invalidates the cache.
* Remember if the cache is volatile in process memory instead of doing
check key lookups for each "big" message to determine this. Use the
message hash in the big message keys so purges to the former chain
down to the latter. An "EXCESSIVE" key/revision map is now used in
the main cache for big messages. This means that editing an existing
big message will result in a different hash value. This is needed so
purges propage correctly.
* Add logging when replace() fails to acquire the lock.
* Factored message cache update code duplication into a new method.
* Use makeKey() in more places, replacing deprecated wfMemcKey().
Change-Id: I82c5baa8137d1ffaaec6adace82ccb0181441342
This reverts commit 9339a08b72
(Change-Id: Idc337a787171949c4f70186b13d7b65304c9b57f).
This is a temporary revert to prevent the change's inclusion in
wmf/1.29.0-wmf.4. That branch is scheduled to be deployed to WMF wikis
during the first week of the WMF's 2016 year-end fundraiser. Since
CentralNotice relies on MessageCache to fetch fundraising banners,
it is preferable not to deploy changes of any significant complexity in
that system at this time.
The original change should be re-applied at a later date. Sincere
apologies to the change's authors! :)
Change-Id: I8330838bbe03ce6ed38fa2e755b44519211d9d43
* Increase time range for getValidationHash() using "latest" values.
The lower value ran the risk of regenerating from slaves and ending
up with *older* data than what was there.
* Avoid cache set() calls in replace() unless the lock was acquired.
Use delete() instead in that case, which invalidates the cache.
* Remember if the cache is volatile in process memory instead of doing
check key lookups for each "big" message to determine this. Use the
message hash in the big message keys so purges to the former chain
down to the latter. An "EXCESSIVE" key/revision map is now used in
the main cache for big messages. This means that editing an existing
big message will result in a different hash value. This is needed so
purges propage correctly.
* Add logging when replace() fails to acquire the lock.
* Factored message cache update code duplication into a new method.
* Use makeKey() in more places, replacing deprecated wfMemcKey().
Change-Id: Idc337a787171949c4f70186b13d7b65304c9b57f
Use HTTPS instead of HTTP where the HTTP link is a redirect to the HTTPS link.
Also update some defect links.
Change-Id: Ic3a5eac910d098ed5c2a21e9f47c9b6ee06b2643
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
Also make use of the cache set options and use
Revision::newKnownCurrent() to avoid excessive
revision table queries during miss periods.
Bug: T144952
Change-Id: Ic1c649478b0f87420052d8c99b2962920f8b5c96
The Config interface (and it's implementation(s)) was never thought
to be an access method for objects saved in the global state, even
if it works with the current implementation GlobalVarConfig.
Imagine, that MediaWiki core switches to another file-based configuratiion
storage or a a database based one, we wouldn't be able to provide
access to global objects anymore, without weird hacks in the new
config-backend implementation or serializing objects to store in
the database or something else. This all isn't the idea with the Config
interface, as far as I know, so don't use it at all.
This commit changes the access to wgContLang to use the global keyword,
instead of accessing it through Config.
Follow up: Ice4f40911c3761c2542430935bc1898bc4e7a4d4
Follow up: I46f376a82205a5c99b98c9e971f9e9d7868ce9fb
Change-Id: I7a08b3bb649898abd445317a523051b07420b211
* Use services container in more places.
* Undeprecated getLocalServerInstance() since $fallback is not
handled elsewhere.
Change-Id: Id1fcd1c465d2d92653357523f4225f1c4d1ace2f
