Paths to ./composer.lock is changed to ./vendor/composer/installed.json
and dependency information now is read from the installed.json file.
A new ComposerInstalled class has been declared and uses the class now
to access the getInstalledDependencies() method to read data
Bug: T106247
Change-Id: Ic216577bb19b4fc5832ba003fcbbe9195d707b41
* All users with the bot right sending requests to
write APIs will get a read-only error when slave
lag is high. The lag tolerance is configured via
$wgAPIMaxLagThreshold.
* Making this lower than 'max lag' in the LBFactory
config means bots get read-only errors before other
users, which is sensible.
* The default LoadBalancer 'max lag' is now 10 instead
of 30, which now matches the timeout used for waiting
on MASTER_POS_WAIT() for ChronologyProtector. This is
better for assuring that users see their own changes.
Bug: T95501
Change-Id: If9d8f4ef47258d5afb7a0e947c6e6f040cbc7e10
Adds the option difftotextpst to ApiQueryRevisionsBase.php, which will perform a
pre-save transform on the supplied text, before diffing it against the
requested revision.
Bug: T53155
Change-Id: Ia480e8cd4ceeeb0b2812dc8ec96650adb83c03af
This is part of a chain that reverts:
e412ff5ecc.
NOTE:
- The feature is disabled by default
- User settings default to hiding changes
- T109707 Touching a file on wikisource adds and
removes it from a category... Even when page
has no changes.... WTF? See linked issue,
marked as stalled with a possible way forward
for this patch.
@see https://gerrit.wikimedia.org/r/#/c/235467/
Changes since version 1:
- T109604 - Page names in comment are no longer
url encoded / have _'s
- T109638 & T110338 - Reserved username now used
when we can't determine a username for the change
(we could perhaps set the user and id to be blank
in the RC table, but who knows what this might do)
- T109688 - History links are now disabled in RC....
(could be fine for the introduction and worked
on more in the future)
- Categorization changes are now always patrolled
- Touching on T109672 in this change emails will never
be sent regarding categorization changes. (this
can of course be changed in a followup)
- Added $wgRCWatchCategoryMembership defaulting to true
for enabling / disabling the feature
- T109700 - for cases when no revision was retrieved
for a category change set the bot flag to true.
This means all changes caused by parser functions
& Lua will be marked as bot, as will changes that
cant find their revision due to slave lag..
Bug: T9148
Bug: T109604
Bug: T109638
Bug: T109688
Bug: T109700
Bug: T110338
Bug: T110340
Change-Id: I51c2c1254de862f24a26ef9dbbf027c6c83e9063
These callers don't need to do purges, but can still perfectly
take advantage of this instance over a plain BagOStuff. Namely:
* Replication and snapshot lag awareness
* Preemptive regeneration
* Easy process cache support
The idea is for there to only be one caching class/factory
to use, instead of having rules for picking which one to use.
Change-Id: I8e362df451c0c28731fc853c044c4c4b8e097f01
This fixes a few shortcomings in the chunked uploader:
* Raises an error if offset + chunksize > filesize.
* Enforces a minimum chunk size for non-final chunks.
* Refuses additional chunks after seeing a final chunk.
* Status of a chunked upload in progress is now available with
'checkstatus'.
Bug: T91203
Bug: T91205
Change-Id: I2262db1bc8460616b069c564475d2e4148001768
I thought it dumped raw text with attached JSON "debugging elements",
but it's just jsonfm with a little extra.
Change-Id: I55f2ae2c9aa295bcb972b4e02e7352532d64341c
This allows generator implementations to define how generator data
about a redirect gets merged into the redirect destination. This
does not change any defaults, only modules that explicitly set a
merge policy will have a change in their results.
This functionality is initially used for the search api modules to
retain search positions within the final result set.
Bug: T92796
Change-Id: If2f49e0fc3176288c95e870240754ee320a6bf91
ApiDelete::delete() and ApiDelete::deleteFile() are altered from public
to protected visibility. This is not believed to affect any extensions.
Also get rid of the token variables, as they are not doing anything useful.
Bug: T108564
Change-Id: I6143043dafa6425a0df4baefe970620cbe69466c
MediaWiki currently has support for a header called X-Vary-Options
(XVO), used to communicate to upstream caches more granular cache
variance options than the Vary header can.
The header was envisioned by Tim Starling back in 2008 and implemented
into MediaWiki and Squid 2.0, with those patches submitted to the
squid-dev mailing list at the time:
http://www.squid-cache.org/mail-archive/squid-dev/200802/0085.html
The patches never actually made it into an upstream Squid release,
however, and Squid has since evolved in potentially significant ways.
Wikimedia has since switched to Varnish but XVO was not ported over as
it was deemed too complex at the time; custom VCL was used instead. To
our knowledge, noone else is using XVO in production and certainly not
with recent, up-to-date MediaWiki releases.
There is currently work at IETF's httpbis working group for a "Key"
header that is in concept and implementation very similar to Tim's XVO
header: https://datatracker.ietf.org/doc/draft-fielding-http-key/
Rather than rip XVO out of MediaWiki, replace it with support for the
Key header, as preliminary defined by the draft spec. This is an almost
straight search-and-replace.
No other software (caching proxy or user-agent) currently implements Key
to my knowledge, so this is essentially untested.
Change-Id: I949fc289dd5d48bd34f3b37f7739e2b9cd5db277
A quick review of usage on enwiki reveals that people are currently
using generator=recentchanges with prop=revisions, so the generation of
revids is not the default to avoid breaking those clients.
Bug: T113884
Change-Id: Ia91af7099120660dc40230b76896090843985d96
