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
This at least doubles the speed, which would allow the number of
iterations to be doubled and computation of the password hash to
complete in the same amount of time as before, or maybe even a
slight bit less.
The doubling in speed is due to an optimization[1] that so far has not
been accepted into PHP's hash extension.[2] In addition, OpenSSL has
optimized assembly-language hash function implementations for several
common CPU architectures. These provide a further, yet more slight,
performance improvement.
While OpenSSL's PKCS5_PBKDF2_HMAC() is not the fastest implementation
around, using it does not add a new library dependency. And although
better password hashing functions exist, PBKDF2 is still the default
in MediaWiki. For these reasons, I think this change makes sense.
[1]: https://github.com/openssl/openssl/commit/c10e3f0cffb3820d
[2]: https://github.com/php/php-src/issues/9604
Change-Id: I7b06590d4c42581f8749336f9c17777f973a506c
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 was introduced in 2015 with 8e3721a2b9 (Iadb34f24d8b, T89308)
as part of the Multi-DC initiative, with the plan being to use this
job when queueng jobs during a requests that are not guruanteed to
be routed to a primary DC (e.g. during a GET request).
Its use was removed as part of T181216, but the job was kept and has
seen numerous maintenance changes since. I propose we remove it as it
is no longer used in any Wikimedia Gerrit hosted code.
The expectation now is that JobQueue backends are responsible for
making sure new jobs can be accepted in any DC. At WMF this happens
by writing to local EventBus/Kafka and the internal streams converging
and mirroring in both directions.
The built-in JobQueueDB implementation is unlikely to be used in for
large wiki farms, but it too would support writes from secondary DCs
from post-send. I haven't tested JobQueueRedis, but it seems like that
could likely also be used in a way that writes locally and replicates
writes from secondary to primary.
Bug: T89308
Change-Id: Ia84d0e9ca047cd78ab8c0d0d055d4199d0e3e5b6
This policy was just the fall-back set in 2015 with the default length
of 1. As pointed out on MediaWiki-l, it is a bit short nowadays, so
raise it to 8 characters, which is what we use in Wikimedia production.
Change-Id: I4e0e57ed910a16804e015c9f1aaf48a5603bf95f
* CDB stands for "constant database" file, hence also changes references
to "constant" when likely intended to refer to CDB.
* Remove reference to non-existent docs/Configuration.md.
* Remove unused resetLocalCache() method. This was documented as
internal for testing only, but tests did not use it.
It was left behind in 2016 with I7d7424345d0ce3ce90 (025f15a208).
Bug: T315315
Change-Id: I61d9689160d9bf5715c4ff18009fbd16236d34e6
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
Instead of checking the result of uncondiional `['host']` access in
the foreach loop afterward, check the result of url parsing directly.
Also:
* Switch to plain parse_url(), we don't support exotic input here.
* Move parsing to loop, minor optimisation, and will often thus mean
we don't even need to parse or check the LocalRepo case, since the
feature is generally only enabled when a cross-domain ForeignRepo
exists.
* Improve docs.
* Remove experimental warning.
Bug: T317329
Change-Id: I6492f5142861513e4a7eb65fe4c14fa12c46977a
The merge of the addition of the new file e36a8af and the creation of
the first patch for removal in the old file b90d2dd overlaps by time and
the information is still there.
Follow-Up: I736cb74efc267fd2473a3267471735238217251c
Change-Id: I6de1e6874206d8a9c7b207b6322d77f6472d22f5
The day has gone. Still keeping the code as the schema changes are not
done in production but the data migration has been finished.
Bug: T299417
Change-Id: I906e069a63d1dae14924c72318b22b16244371d6
The authentication provider's testUserForCreation() method is for
checking whether a given user name is available. The current
user being IP-blocked has nothing to do with that username's
availability so stop checking that. (AuthManager will check it
via AuthManager::authorizeCreateAccount() elsewhere. Although
that method doesn't seem to be doing anything useful and could
probably just be replaced with a direct call to
PermissionManager, but that's left for a separate, less risky
patch.)
Special-case autocreation though, which doesn't use
the more appropiate AuthManager::authorizeCreateAccount() for
performance reasons so it does need an IP block check.
(At least I think it is for performance reasons. Maybe it's
just an unintentional omission, and that should be used instead?)
While we are at it, also fix a TODO in AuthManager where partial
blocks were taken into account for $wgBlockDisablesLogin, and
clarify in the config schema that they aren't, improve some
comments to make it more obvious why some things are/aren't
done in CheckBlocksSecondaryAuthenticationProvider, and make
the logic more similar to the one in testUserForCreation().
Functional changes:
* Partial blocks are ignored for authentication, account
creation and autocreation.
* On $wgBlockDisablesLogin wikis IP blocks won't prevent
login anymore.
* On $wgBlockDisablesLogin wikis, blocks will now prevent
account autocreation even if they are not configured to
prevent account creation. The assumption is that on such
wikis account creation is restricted via some means.
This probably isn't necessary as blocks should also prevent
the conditions needed for autocreation (e.g. log the user
out centrally), but can serve as defense in depth.
Along with the special-casing of autocreation, this means
on such wikis any IP block will prevent autocreation, which
is not great but seems not worth even more code complexity
to avoid.
* The action=query&list=users&usprop=cancreate API won't take
blocks into account anymore.
Bug: T306018
Bug: T208895
Change-Id: Ie94d61640301192b287275311f3452e606469d25
We’ve been using it in production for two months without issues as far
as I’m aware, so let’s start documenting it as a more permanent feature.
(After all, people querying the table, e.g. via Quarry, need to be aware
of it.)
Bug: T306589
Change-Id: I66d405b34f02c57a337d196124c0d5a4d3a3b20b
When $wgWatchlistExpiry = true and a user adds a page to their
watchlist, they are currently presented with a combo box where they can
pick a duration of permanent, 1 week, 1 month, 3 months, and 6 months.
This patch adds 1 year to the combo box, and raises the maximum age to 1
year. `api.php?action=watch&expiry=1 year` will now also work.
Bug: T313255
Change-Id: Ia84d6f99584ae23feea3831499d5baee2dd1a024
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
This ensures we don't show ToCs in vector-2022 for Javascript pages
which contain raw <h2> elements.
This version uses the same "canonical options" hack that is used for
language conversion tables. These should both be replaced by a
(not yet existing) mechanism in the future: T313455 is the
task for that.
Bug: T307691
Depends-On: I35e199cca40c0e4359ac493e5806dcf4ae49321c
Change-Id: Iba6a8b6c59bf91e3d06896f0a610c3c3e52e6564
Validating against the live schema on the WMF cluster exposed several
issues with the config schema. Mostly settings declared to be lists
which are actually associative arrays.
This also removes deprecation markers for some settings that are still
in active use, just discouraged or unstable.
Change-Id: I63e816edd1a561bda6063f8558ccce88c113df3f
This adds functionality to SettingsBuilder for collecting warnings to be
logged later, when the logging mechanism has been set up.
This also adds a validation step to update.php that aborts the update
if any warnings have been registered in SettingsBuilder, or the settings
fail to validate against the settings schema.
Change-Id: I387905289fb93591f79b96bf4c6cb5ec692b2aff
I don't recall why I added this. Possibly in a confused effort
to match /tests/phpunit, except /tests/phpunit/suites is not
where test cases live, they live under /tests/phpunit/* directly,
mostly /tests/phpunit/includes named after the source directory.
The correct equivalent to that is /tests/qunit/resources for JS.
While at it, also remove mention of this concept from various other
places where it doesn't add value. It's one more word/concept to
learn, process, understand, or translate mentally. They're just tests,
or for the one or two places where we care about how they are
internally transmitted, a "test module".
Bug: T250045
Change-Id: I5ea22e4965d190357aa69883f29f9049ee8ebf13
- schema change to allow tl_namespace and tl_title being empty
This is done by removing them from primary key. They don't need to be
nullable as they have default value.
- Make sure with WRITE_NEW, updater avoids writing to the old columns
Bug: T306674
Change-Id: I2b8a29043e952060e7a79b6a7a3d647d48cd16fb
Apparently, $wgLocaltimezone is set to the empty string in many
existing LocalSettings.php file, presumably because the installer
failed to detect the correct time zone.
The new code for handling automatic defaults will only trigger if
$wgLocaltimezone is null, not when it is otherwise empty.
This adds fallback code in strategic places to ensure that the empty
string is handled correctly.
Bug: T305093
Change-Id: I39226466f2bb6a36823ae9032fc62f981eabc64a
The goal is to keep the actual default values for settings in the same
place as the setting is declared, and applied using the regular means
for loading the settings -- not in a separate piece of code that needs
to be loaded through some entirely different mechanism.
SetupDynamicConfig.php now contains a few categories of things:
* Post-processing of configuration settings, where already-set settings
are altered. This could be moved to MainConfigSchema too as a separate
set of methods.
* Processing of old aliases of settings (blacklist, slave) that are not
registered as settings anymore and therefore are not available to
MainConfigSchema. This could perhaps be moved to LocalSettings
processing somehow?
* Setting $wgUseEnotif, which is also not registered as a setting.
Easiest would be just to declare it as a setting and have it set
unconditionally.
* Setting the actual timezone to $wgLocaltimezone. This is not related
to configuration and should just be in Setup.php.
Bug: T305093
Change-Id: Ia5c23b52dbbfcb3d07ffcf5d3b7f2d7befba2a26
Unused since change I88754b52c2 (commit 9e95539fc9) – this was only used
for SessionProviders, which is now a map/object instead.
Change-Id: I8da686e6379eb33a63799874fb44f9b0030ab5ba
A library for storage of counter value time series statistics, based
around the observation that memcached getMulti() is apparently fast
enough to do this in a simple manner, with incremented values stored
in time window buckets.
Bug: T310662
Change-Id: I26b1cdba0a06ad16ad8bb71b455e1b6180924d17
This adds support for JSONSchema style property declarations with nested
schemas. This is a step towards using more nested structured for
configuration, rather than adding to the over 700 keys already defined
in the main config schema.
Defaults from property schemas are aggregated into a default value in
the top level schema. Descriptions are however not yet aggregated.
Change-Id: Iaf46a9ecc83bee3566098c56137a1be66bff2ab9
This patch introduces a ParsoidOutputAccess service for
getting parsoid outputs and warms the cache with pregenerated
outputs.
It also introduces a config variable in ParsoidCacheConfig that
is turned off by default for controlling the cache warming.
Bug: T301371
Change-Id: I6152c42ea765d94093d8d62598b1b4278314adec
