* The '.php5' entrypoints were deprecated in I68b1ae842, $wgScriptExtension
in I3690f78bc.
* Drop the associated ResourceLoader configuration variable, too. `mwgrep`
shows no usage in the MediaWiki namespace.
* Keep the scriptExtension configuration parameter for FileRepo for people who
would like to interoperate with older MediaWiki installations that still use
'.php5'.
Change-Id: I17c8a15484b7e82cd5970d34e688109a2aae3840
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
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
* $wgCdnMaxageLagged controls exactly what that TTL is
and the usual "max lag" settings determine what "high"
is for lag (which already makes the site read-only).
* This helps avoids stale content getting stuck in CDN
for a month just because a slave was lagged for a minute.
Of course race conditions with normal slave lag and WAN
cache relay purges can still lead to this problem, though
the scope of it is reduced.
Bug: T113204
Change-Id: I7ff0a8d88665f4e557566e7b412e75edee2627fe
* Simplify the debug log call and use queries group
* Remove $wgDebugDumpSqlLength, as profiler output
already has shortened query strings (one can use
profiling without DBO_DEBUG)
* Removed $wgDebugDBTransactions as BEGIN/COMMIT already show
* Removed PostgresTransactionState as it was only used for
$wgDebugDBTransactions handling
* This cuts down on lots of global variable usage
Change-Id: I185adb1694441d074dea965960429b4910727620
* This is used to set sticky DC cookies to avoid
session replication lag (which also makes sure
ChronologyProtector works)
Bug: T91816
Change-Id: I7bc2f8185a3c05cb3ca5ccc42d300eccffae48e1
When minifying JavaScript, never put each statement on a separate line, and
always set a target maximum line length of 1000. These behaviors were
previously configurable via $wgResourceLoaderMinifierStatementsOnOwnLine and
$wgResourceLoaderMinifierMaxLineLength, respectively.
Change-Id: I0b0eb632875b5e16f728fd0aa62f7f5ecd79ef62
* This jobs should only be constructed via relevant Content object,
e.g. the result of enqueueUpdate() being called on a DataUpdate
returned by Content::getSecondaryUpdates().
* Also modified LinksDeletionUpdate to support a $pageId parameter.
* LinksDeletionUpdate can now be enqueued to a DeleteLinksJob.
Change-Id: I650dcf0bd172ede0d61357ec158a4704ae1f2033
Deciding how to behave randomly is useful for testing, yet misleading
for general usage. Now that testing is over, make it a boolean switch.
Change-Id: I3e4d02aa57c853c20152c9071c444e09da57fb35
This localize the protect type, level and expiry on Special:Log/protect.
To allow i18n there are some details stored in the log params of new log
items, these details also shown on API output.
The details cannot get from the old existing data, because there are
containing L10n strings therefore i18n works only for new items.
In the api and for IRC the old description text is still stored in the
log params for backward compatibility.
This allows use of gender on Special:Log. Old messages are kept for use
in IRC. Tests already exists to ensure an unchanged IRC message.
Bug: T47988
Change-Id: I3bb85c61b857972e66c99c499d7d785c88cafb25
This setting allows blocked users to edit their talk page, unless
talk page editing is specificly revoked in the Special:Block screen.
Almost all Wikimedia wikis do this, to the point where many people
don't even realize it's a config option.
Note: Existing blocks will not be affected by this setting change.
Change-Id: I05194f3fb313098284c474c948d7d26541ab6094
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
This is completely ignored by the API and never made it into a stable
release - it was added and removed in 1.21.
Change-Id: I87a8df78a4bcffae9bbd51faa1137abb1faf2aa2
* Split tidy implementations into a class hierarchy
* Bring all tidy configuration into a single associative array and
deprecate the old configuration.
* Remove $wgAlwaysUseTidy
This is preparatory to replacement of Tidy (T89331). I used the name
"Raggett" for things relating to Dave Raggett's Tidy, since if we use
"tidy" to mean the new abstract system as well as Raggett's tidy, it
gets confusing.
Change-Id: I77af1a16cbbb47fc226d05fb9aad56c58e8910b5
Deprecated in 1.24, for reasons explained in a0c41ae39d. I don't see any
usage in core or extensions.
Change-Id: I46f9e04ae633e7ff1ee112b652e1865731172f1f
This make re-configuring these much easier by only needing to update
one variable instead of four.
Also remove redundant hardcoding of wgStylePath and wgResourceBasePath
in the generated LocalSettings.php file during installation. This way
changing wgScriptPath will naturally result in the other variables
updating too. We already do this for many other variables (such as
wgLoadScript, wgScript, wgExtensionAssetsPath, etc.).
Change-Id: Ide74355b4054c78214c17f3b2d6fa2f5270e0ab9
Update the ParsoidVirtualRESTService and the
RestbaseVirtualRESTService to use Parsoid's v3 API, instead of the
deprecated v1/v2 APIs. Since Visual Editor still issues requests
using the Parsoid v1 API, convert Parsoid v1 API requests into Parsoid
v3 API requests when needed for a smooth transition. We also add
support for converting RESTBase v1 API requests to Parsoid v3 API
requests.
The next step will be to convert Visual Editor to issue RESTBase v1
API requests (https://gerrit.wikimedia.org/r/217995), and then the
Parsoid v1 conversion code added here can be removed (T100681).
Tested Parsoid v1->v3 conversion, Parsoid v1->RESTBase conversion,
plus Parsoid v3 and RESTBase v1->Parsoid v3 conversion using VE
patched to issue RESTBase v1 API requests.
Bug: T100681
Change-Id: I07ac60cdec7a52ef93187d40099325a069e3239a
Using $wgExtraNamespaces overrides any localized namespaces with the
canonical form, which is not ideal.
Namespaces added through extension.json will now store the canonical
form and numerical id in a 'ExtensionNamespaces' attribute that is read
by MWNamespace::getCanonicalNamespaces().
Also fix the documentation on $wgExtraNamespaces, as using
$wgCanonicalNamespaceNames has not been possible since r85327.
Bug: T110389
Change-Id: I5bd9a7258f59d8c4a7ad0543d2115960fbea9b3a
Follows-up d7905627fd which makes all script loading asynchronous,
thus obsoleting this experiment.
We do still have separate top and bottom queues, but that's tracked
under T109837 for later consideration.
Change-Id: I1d6ea47c59bb47977594aff94952a38cc0a9ce34
Migrate the move protect log as first sub type of the protection log,
because it does not have complex log parameter, which needs some way of
handling/migration.
It also keeps the gerrit change smaller and hopefully makes review
easier.
The other sub types of the protection log will be migrated in a later
patch set.
This allows use of gender on Special:Log. Old message is kept for use
in IRC. A test was added to ensure an unchanged IRC message.
Bug: T47988
Change-Id: I57b3bd8a7dc823acdbb56520d2364f5542283373
* Potentially long running POST requests often use multiple transactions,
talk to multiple services, or defer updates. Try to make sure they have
a chance to complete all of the work. WMF already sets ignore_user_abort()
across the board in config, but this applies it to key spots for all
installs, in addition to bumping the time limit.
* Eventually this can lower the need for high overall time limits.
Bug: T102890
Change-Id: I893ddd773064dcd63b5b24c84c6391974f4b5aee
This ensures 'wikibits' and 'mediawiki.util' (if so configured)
finish loading before executing other modules.
This was previously implicitly provided for the bottom queue by
being in the top-queue, but since this is now asynchronous that
is no lower guaranteed. Fix this by making this explicit instead
of implicit.
Keep them in the top queue as-is to ensure consistency with cached
pages and it allows them to preload and batch in the same request
instead of being discovered later at run-time as a separate request.
Bug: T108124
Change-Id: I74e0cbe616404da927ea46d06308a7bae930eb69
Most wikis only use user signatures on pages set aside from discussion,
(Talk namespaces and sometimes project/main namespaces depending on
the wiki), so having the button available everywhere is confusing.
The few wikis that need the button (especially non-content,
internal/corporate/planning wikis), can add relevant namespaces to the
$wgExtraSignatureNamespaces array in LocalSettings.
This would make it possible to solve bugs like T59727 or T53154.
Since this is a change to default behavior, a release note is added.
Bug: T7645
Change-Id: I7ccf1093b888c7b33721234349ca0ac054c3cd3f
These were never enabled or used in production and are not
compatible with the upcoming async changes (T107399). To avoid
having to maintain compatibility with this, remove it for now.
The current on-going request to operations for ESI support is unrelated
to this code.
Considered making makeResourceLoaderLink() protected as it's not
used anywhere in @wikimedia Git outside mediawiki-core. And the unit
test actually treated it as protected already. However it's called
in SpecialJavaScriptTest so leaving that as-is for now.
In Icba6d7a87b239 the signature will change again with the removal
of the $loadCall parameter, which is obsolete in an async world
due to document.write being forbidden.
Change-Id: I9f557cc794638ffd15329934865e21e1027f7cfa
If the user gets zero results, but gets a "Did you mean" result, just
run the query for the "Did you mean" result and inform the user that
this happened. Adds a new query param 'runsuggestion' which will, when
given a falsy value, prevent running the suggestion and give the result
to the original query.
Bug: T105202
Change-Id: I7ed79942c242b1957d46bdcad59985f37466fb83
People use mediawiki for all sorts of things, restricting to
2048px wide seems much to strict as the default setting (imo).
It should be noted, MediaWiki, can, in the default config
(but with some non-default user prefs), include images of
up to size 2560 px on the image description page, so the max
svg size should at least be that big.
Change-Id: I306a792e61e7c738982b9dbde8a63aa31acf38a8
Note: this doesn't affect WMF, as they have it overridden to 4096
It was not only for worries about large wikis, see 3ef8a83c0.
Wikipedia has been using it for a long while.
Change-Id: Ibab7fa860ba3ab56366c63626516e69984cd1934
* This setting works fine for WMF, including various extensions.
It seems a better default than just pruning out failed jobs.
Change-Id: I635880a49f50544433559ef2cbfb218783b32534
In actuallyNotifyOnPageChange, the $wgEnotifUserTalk is inside
a check involving $wgEnotifMinorEdits, so it won't fire if
it's a minor edit and $wgEnotifMinorEdits is false.
Change-Id: I6576cb1735db5d9288257e6877b8755450d0dacd
