This setting can be used to optimize externallinks queries for certain
domains that have many entries in the externallinks table, but also big
“gaps” where the table contains no entries for that domain. By putting
those gaps (whose el_id values would usually have been obtained on the
analytics databases) into the configuration, we can have MediaWiki tell
the database to skip those ranges of the table instead of scanning
through them. (This is only relevant for domains that have enough
entries that the database chooses to scan the table in primary key order
rather than using the el_to_domain_index_to_path index and filesorting.)
Bug: T341000
Change-Id: Iec4fe01aaa595fbaf3b427b7baa68a9d7209b117
This moves the core part of wfGetPrivilegedGroups() out of Wikimedia
config and makes it possible to move functionality built on it into
core.
Bug: T208477
Change-Id: I6536ef2909caeed047447e8b6a25831d6f00d827
Building blocks of CP don't really need to depend on LBF. Even the
config value for CP stash type is also different. But it's being passed
around along the rest of LB/LBF config and possibly down to the DB
object.
This is making the code much harder to understand, adds more coupling
than it needs to, and it's making pieces that don't need to rely on LFB
(like load.php) actually depend on LBF just to disable CP.
This clean up also helps improving DI of LB/LBF and building of DB
objects down the road.
Bug: T275713
Change-Id: Ic27269a1f1190ee7a03c6a422ada7ff293c3cab1
In the debugger of Firefox and Chrome, without any special debug mode,
you will be able to see the original unminified JavaScript source, and
to set breakpoints in it and step through it.
Main visible changes:
* Add a config variable controlling the generation of source map links,
off by default for now.
* For script responses, move errors to the bottom of the response. This
avoids disturbing the source map.
* mw.loader.impl() calls will have less whitespace in debug mode,
because minification is no longer done as a post-processing step on
these calls.
Details:
* Use an index map when multiple responses are requested. This requires
an update to the minify library.
* Add a boolean "sourcemap" query parameter which causes load.php to
deliver source map output instead of regular minified content.
* Bundle sources into the source map and use two kinds of fake URL if a
real debug URL is not available. "Open in new tab" on a fake URL is
not functional.
* In the source map mode, respond with 404 if the version is mismatched
or if the content type is unimplemented.
* Fix createLoaderURL() so that $extraQuery is not ignored when there
are conflicting context parameters, so that we can successfully
override the version. The source map version should match the
delivered content, not the requested version.
* Since minification with source map tracking can't use filter(),
add a new cache for module source maps and minification. Add hit rate
stats.
Also:
* Fix unnecessary array_map() in getCombinedVersion()
Bug: T47514
Change-Id: I086e275148fdcac89f67a2fa0466d0dc063a17af
Mark as deprecated now that it's false by default and deployed as such,
so that we can remove all the dead paths in a future version.
Bug: T314318
Change-Id: If514d058cc92408c67ffb7625e47f224bb510838
Move parts of implementation code comments into something that is
discoverable and understable to a general audience of MW core and skin
developers (not hidden in code mostly seen by maintainers
and contributors to ResourceLoader internals).
Most notably, that the system is turned off by default (and how to
turn it on), that it is limited to requests by unregistered users,
and that the class must follow a certain pattern.
$wgResourceLoaderClientPreferences is removed as part of this.
This is not considered a breaking change as the feature is now
automatically on in the skins needs it (via skin.json), and previously
it was marked experimental and off by default.
Skins are naturally required to have knowledge of this system, as they
need to call into it to persist classes for feature toggles. By removing
the need to also enable it at the site-level we get a few benefits:
1) make skins like Vector easier to correctly install and configure.
2) ease maintenance for skin devs by removing the need to manually
export and check $wgResourceLoaderClientPreferences before calling
mw.user.clientPrefs or otherwise hinting in UI or docs that the
feature persists when it might not be turned on on a given MW site
or WMF wiki.
3) ease browser testing in CI.
Bug: T344069
Depends-On: If9b83dd559cda2dac315afcb65a4761b9e97f319
Change-Id: Ib0b5ee29ec7accb7b291830d2ab6566fe4f4c0c5
The global variable AjaxUploadDestCheck is deprecated and unused since
6c4ac7ddc5 included in MediaWiki 1.38.
Bug: T291375
Change-Id: Ie406adb97bf323cc54041aca2b0204db8b4da859
In https://gerrit.wikimedia.org/r/c/mediawiki/core/+/745386 and
https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/thread/ASODV6622T4YUAY3JO5ZVBL3B5ZQDX2U/
a compelling case is made that we can drop $wgLegalTitleChars as a
configuration option. Extension::TitleBlacklist or, in the near
future, Extension:AbuseFilter can be used to restrict the character
set for those who still have that need.
Similarly, it doesn't seem compelling to make IllegalFileChars
configurable; probably most libraries don't even realize that the
set of legal title characters after a `File:` prefix is different
from the set of legal title characters, and of those that actually
implement this, probably no one is actually respecting a reconfigured
value for $wgIllegalFileChars, because it's not even exported in
siteinfo.
A patch to remove the configurability will land later (probably based
on I70b60ca548e36c676da90553ad8684507096bb28) but for now let's just
announce our intention to fix the set of legal title/file characters
for all wikis and let that ride out into the world in our next
release.
Bug: T297340
Change-Id: If48257ff6e800451b992ed0748abc878fa5e16d3
This adds the core parts of the feature with only the minimum
possible functionality: saving while editing; restoring
when an edit form is re-opened; and deleting (on saving etc.).
Bug: T341844
Change-Id: Ie556a7c981c68e8fe98deba8bf7995bf6c27ecd3
Since the default for wgParserEnableLegacyMediaDOM is now `false`, this
config will also be set to `false` and wikis can enable it while it's
still necessary.
The plan will be to gradually roll this change out, as was done for
wgParserEnableLegacyMediaDOM, to develop a migration path for templates
and extensions that mimic the legacy media output.
We can start on officewiki.
Bug: T318433
Change-Id: I70e537b2beb99de9a41e7dc66a0d60a508009887
Add a switch that allows toggling between inline and two-column format
when Wikidiff2 is installed.
Inline toggle should also support no-JS toggling
The legend should toggle when switching from table to inline after the
first load.
Introduced a temporary feature flag to show this inline toggle so that
we can merge and easily continue the improvements. It will be removed
when ready for production.
Bug: T336712
Bug: T330229
Change-Id: Ie6a48e495f2bb299d8b984e7c40363d534c7915b
The MediaWiki\MainConfigNames class was added
in I817dc14c4ce8fc0a29d9c07e8fd393c4f359cade
which is not in 1.38 but only in 1.39 and later.
Change-Id: Ic25e64d109defc970c90e038a7de03d4ca8ed82c
This was a temporary flag to allow setting the migration stage for a
comment migration with a temp table.
Since the rev_comment_id migration is done, this is no longer needed.
Dropping the compatibility code for temp tables will be done in
follow-ups.
Bug: T299954
Change-Id: I290a74f27b05cd7e062dda78766911ffe3053d08
- [x] Add Wikimedia Icons to project
- [x] Fetch Interwiki icons if they exist
- [x] Fallback to previous functionality for icons not available in OOUI
- [x] Create config to override icons
Bug: T315269
Change-Id: I5d904e467a978847bbc9af65fdba1ef729068993
Add wgSVGNativeRendering to allow clientside rendering of SVG files
Default is false. When enabled with true, will serve ALL SVG files
as is to the browser.
When set to the string 'partial' it will conditionally serve SVG
files based on criteria. Currently it will force PNG rasterization
for translated SVGs and for SVGs over wgSVGNativeRenderingSizeLimit
wgSVGNativeRenderingSizeLimit is a byte size limit to avoid larger
SVG files (potentially much bigger than a PNG) from being served
directly to browser.
Native SVG rendering does not provide PNG fallback. SVG support in
browsers has evolved far enough that this should rarely be a problem.
Bug: T208578
Change-Id: I9647fdd72f868c821eb20f67b239826f23655a1c
We always wrap the local cluster cache, and there are no subclasses
of WANObjectCache. It was never documented or recommended how these
would be used. It is a left-over from the original 2015 Multi-DC plan
in which WANObjectCache would work differently. See task for details.
Note that this requires no configuration changes, even in the
theoretical case of these variables being used, as the only
option is to use the main cache, and that's also the default.
* Update WAN overrides to override the underlying main cache
instead.
* Fix EditPageTest which was previously implicitly using a 'hash'
as main cache but also relying on wan cache to be 'none'.
The part that it actually needs is the 'none'. When WAN cache is
enabled, testUpdateNoMinor fails due to an edit conflict because
one of the edits it makes is made with a current timestamp whereas
it expects to simulate wpEdittime in the year 2012 which, when
caching is enabled, is ignored and becomes the current time instead.
I don't understand exactly why, but I'm going to conserve that
behaviour for now.
* Fix TemplateCategoriesTest, which was failing due to an unexpected
cache hit:
> [objectcache] fetchOrRegenerate(…:page:10:…): volatile hit
This could be solved in a more realistic way by splitting the test,
or by explicitly resetting services half-way the test to clear
WikiPageFactory, PageStore and WANCache process state.
For now, keep the prior behaviour of no cache in this test.
Bug: T305093
Bug: T329680
Depends-On: If890622eed0d0f8b4bd73d36ba1815a3d760ea05
Depends-On: Ie1def75208822bdf19bb2cfd7e6edf32c2000e6b
Depends-On: I35cce61dc3ee90dcee3dd6f0b36f84133be029ed
Change-Id: I53781a8c06ebb2583f6ca83dd91bbfe8a5c88b13
This supported mostly IE 6 and 7 as well as some very old Safari
versions against sniffing. Browsers later implemented
X-Content-Type-Options: nosniff which should protect against this
problem.
Bug: T309787
Change-Id: Iea61bd82033551008eb1832fe899ea28ccb23385
generateConfigSchema.php was already generating all other files
directly, MainConfigNames.php was the only one based on the template.
Given the template was trivial and unlikely to change, this change
removes the template and changes the script to generate
MainConfigNames.php directly as well, in the name of consistency and
simplicity.
Change-Id: I7e7f2bfbc232d2ee6582638ced74b3e929be21ed
This allows the body classes of skins to be customized for anonymous
users. Enable using $wgResourceLoaderClientPreferences = true;
* Only classes of the form <prefix>-(disabled|enabled)
can be toggled.
* For now no client side API is provided as this should not be
considered stable.
* Storage mechanism is cookie, stored under "mwclientprefs"
* Preferences apply to all skins. This means setting a preference
in Vector 2022 would also lead to class manipulation in Minerva.
This is by design to allow for skin-agnostic preferences. Up to
caller to make sure the class being manipulated is limited to the
skin if required ie. don't use generic classes.
* Avoids try/catch and JSON parsing by storaging as a string
* Places inline script before body tag before first stylesheet to
avoid breaking the article's ability to parse the article
concurrently with stylesheet download.
Usage:
Given a document with classes
"client-js vector-feature-limited-width-enabled ext-feature-enabled"
Set:
document.cookie = 'mwclientprefs=vector-feature-limited-width'
Will result in toggling off the limited width.
Bug: T321498
Change-Id: Ic3b6eec19953932c697ab5bf48c33a4ac1841b07
This was marked as deprecated to indicate that it shouldn't be used
to share arbitrary database tables between wikis. However, this has
never been officially supported and so doesn't actually warrant
deprecation.
The only use case for $wgSharedDB that MediaWiki supports (and even
encourages in documentation) is for global accounts shared between
wikis.
Recently, update.php started to block upgrades when a deprecated
setting is used, which has brought this otherwise-innocent deprecation
comment to light. Remove it as such since the feature for which it
exists isn't deprecated, and we don't have any other (supported and
documented) ways of sharing accounts between wikis.
In the future, we might rename this and turn it into a boolean so
that it is easier to understand and maintain, but that's for another
day.
Bug: T308536
Change-Id: I1598630f2ab2c9bd443a5f3e6fc0997ceb52c5b2
This patch introduces a configuration variable that allows one
to control the migration stage in production.
Bug: T299954
Change-Id: I36f1e3cd9fb0f25fd43f4dbb97f791da5eb1147b
Code moved as-is from the extension repo with minor changes:
* Adopt PSR-4 namespace.
* Keep backward-compatibility with "PoolCounter_Client"
in LocalSettings, from before the extension was namespaced recently.
* Document how `connect_timeout` actually works, and that it
was introduced in MW 1.28 (via extension).
* Add stable interface annotations.
Bug: T201223
Change-Id: Iadec5b4b5d2fc7e76509c9be0a8fa605d95c64a7
This restores a rewritten version of
commit 78483caaaf.
- Special:Contribute the default entry point in the menu when enabled
- Otherwise it will link to Special:Contributions (default behaviour)
Depends-On: I65336cfd56e1f6b92c1b3bc83cb5d91bbca065bf
Bug: T319327
Change-Id: I67779b88c4904462f9d847b3edb08a65306b2bfb
Introduced in 2017 with I7f14b9ca2533032 (2e5eb693) but remains
unused at WMF, and disabled by default.
Follows-up I62107789fa (9e49260fc9) which added reap to LinkCache
test cases in 2021.
Change-Id: I0654c29a671467dd6b366f462d1c09b90a273413
This only supports WRITE_BOTH for now, the rest will be implemented.
Tested locally, works fine.
Bug: T318606
Change-Id: I6f898aa89f7d36f3f8a4eb8c23706c64a90896b0
This allows config variables to be declared obsolete. Obsolete config
will be omitted from the schema, defaults, name constants, etc. The
purpose of keeping a declaration of obsolete config around is to allow
the updater to warn admins that they are using a config variable that no
longer has any effect, and provide them with a remedy.
The idea is that support for deprecated config can be removed after one
release per the stable interface policy, but the declaration of
obsolete config should be kept for as long as we support updates,
that is, at least two LTS releases.
See https://www.mediawiki.org/wiki/Topic:X4bh4nf3pe2ho5jj for
discussion.
Change-Id: Ia7a00742ea7a5311e820a6a43b11135a3f2a825f
This global variable was replaced by auto-discovery of parser test
files in extensions and is no longer needed (or used).
Change-Id: Ib616e60f36db32ffd8bc69c71a096f23c0a27910
What was previously a REST API-only feature (the thumbnails
hook allowing for thumbnails for non-file pages via the
PageImages extension) is now also being adopted in the main
search page.
That hook will now be called with NS_FILE result thumbnails
pre-filled, which was not the case previously. PageImages
essentially duplicated NS_FILE thumbnail logic that was
already present in Special:Search, so that can (and will
in a follow-up patch) then be removed there. Special:Search
will then simply take whatever is produced from the provider
(which will include both NS_FILE thumbs - which it handled
already - as well as whatever else it receives from the hook),
as will the REST API (which already received both)
Since thumbnails can now come in for multiple namespaces &
having some of those results with & others without a thumbnail
can be quite jarring, it was decided that we'd display
placeholder images (for certain namespaces). This is now
controlled by $wgThumbnailNamespaces.
I also split up a few things in FullSearchResultWidget::
generateFileHtml for more clarity.
Meanwhile also updated mediawiki.special.search.styles.less
to use variables for known colors.
Also implemented a 'transform' (required for testing this
change properly) and 'getDisplayWidthHeight' (it became
needed after implementing transform) callback function for
mock Files, and updated some existing tests in response to
these changes.
And some more Rest test files have been updated to allow
passing around a HookContainer instead of only an array of
hooks (from which a new HookContainer would then be created)
to allow the same container to be used across all relevant
objects, who may have it injected as dependency.
Bug: T306883
Change-Id: I2a679b51758020d3e822da01a1bde1ae632b0b0a
This reverts commit cfed8e7743.
Reason for revert: Will implement a hook rather than changing config at runtime
Change-Id: I5a941b871f9a6347744e800ea63cd82450ab6da3
This patch changes the Special:Preferences menu layout to display as a vertical menu. This function will only work for users with AMC enabled.
It also creates a variable (SpecialPreferencesUseMobileLayout) that changes when a user navigates to Special:Preferences on mobile and has AMC enabled.
Bug: T311717
Change-Id: Ia7a730cd7f009dbb921a810f27fae4a9ee66f793
When the deprecation of wikibits.js originally started, it contained
a ton of things [1] such as:
* user-agent utils, `clientPC` and `is_gecko`.
* addOnloadHook.
* importScript.
* appendCSS.
* stylepath and other config vars.
* tooltip, e.g. updateTooltipAccessKeys.
* portlet, addPortletLink.
* tablesorter, e.g. ts_makeSortable, ts_getInnerText
* searchsuggest.
* notify utils, e.g. jsMsg.
* spinner utils, e.g. injectSpinner.
* event utils, e.g. hookEvent.
* siblings scripts included: mwsuggest, sajax.
Except for two (addOnloadHook, and importScript), these have all found
new homes and been succesfully migrated and replaced over the years
with other platform APIs.
The $wgIncludeLegacyJavaScript variable hasn't been needed for a while
as what it gated no longer exits. Remove it and fold the two remaining
functions into mediawiki.base as defacto stable APIs.
* addOnloadHook: Not worth breaking imho. I've shortened the
implementation which saves a few bytes in WMF prod, and adds a few
bytes for CI/third-party where it was previously absent for new
wikis (thus reducing portability).
* importScript: Never deprecated in the first place as there is no
mw.loader equivalent to this. In order to achieve optimal cache
performance, and benefit from automatic purging after edits, one
must craft a very specificly encoded and ordered canonical
action=raw URL. This is not something end-users need to know about,
and is what imporScript exists for to abstract. Plus, it ensures
de-duplication. One day something like Gadgets 3.0 (T36958) might
take off, but for many years to come, importScript remains the best
and only supported and usable means within the platform to share
and load user scripts.
Tested with: `curl 'http://localhost:8080/w/load.php?modules=mediawiki.String%2Cbase%2Cuser%2Cutil&skin=vector' | gzip -9 | wc -c`.
Before: 9.53KB
After: 9.45KB
[1] https://gerrit.wikimedia.org/g/mediawiki/core/+/1.17.0/skins/common/wikibits.js
[2] https://www.mediawiki.org/wiki/ResourceLoader/Migration_guide_(users)
Change-Id: I10f17f68fea862d510d188b927f4a7b38be0e4a4
MediaWiki sets a large 'Cache-Control: s-maxage=' directive on page
views only if the request URL matches one of the normal CDN URL forms.
When MediaWiki is behind a CDN that re-orders query parameters on
request URLs, we want the CDN URL matching logic to be insensitive to
the order of query parameters. This change introduces a
'CdnMatchParameterOrder' configuration option that can be used to
control this behavior. It defaults to 'true', which preserves the
existing behavior (order-dependent matching).
Bug: T138093
Change-Id: I3c52ca47e095ba32511892853dac6c87a1cc2321
Remove Flash cross-domain policy mangling. Users who are somehow still
using Flash as a browser extension will be exposed to CSRF
vulnerabilities.
Deprecate the config since deprecation has some advantages in the new
config system over simple removal.
Bug: T279496
Change-Id: I2c0e85a430d7e6aaf8d5decd00cf1dade04cebe1