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
This seems like a (slightly) cleaner system. We'll need to change
some documentation and add some configuration, but at least this will
be easier to handle.
Bug: T114765
Change-Id: If962fd3066e25e43e745efd29058eae82195bfb1
Mention action=query&list=pagepropnames to get a list of properties in
use.
Also rephrase apihelp-main-param-uselang to use active voice.
To test, visit
api.php?action=help
api.php?action=help&modules=query%2Bpagepropnames
api.php?action=help&modules=query%2Bpageswithprop
Change-Id: Ic13f6c00396aed1a1c016bfcf6a39d621a4ebc06
* Change "retrieve" to "parse" (according to Anomie's comments).
* Split the first sentence for easier understanding and translation.
* Rephrase the last sentence about "new"'s validity to be more
precise and less English-centric.
Change-Id: I71473fb186ded9e9929682d145a2381becf68767
Changed some old bugzilla links to new phabricator links in comments,
test data and error message. This reduces the need for redirects from
old bugzilla to new phabricator from our source code.
Change-Id: Id98278e26ce31656295a23f3cadb536859c4caa5
The code for the rdnamespace parameter to prop=redirects was trying to
use a nonexistent rd_from_namespace field when miser mode was not
enabled.
Bug: T113453
Change-Id: I7ef77a01c25fec34623b888f439261423cebdaef
Currently import sources have to be set into $wgImportSources as part of
wiki startup. This is not practical for the WMF cluster, where we need some
reasonably complex logic to set up the import source structure.
This change allows the import source list to be populated from a new
"ImportSources" hook. This hook is only called when the list of import
sources is actually needed (namely, when a user with relevant permissions
loads Special:Import).
Bug: T17583
Change-Id: Ice9a19cb6dfe53ae72aa71353d0553ee9338f233
