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 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
This changes the name of a key in the ParsoidCacheConfig array:
StashType is more in line with other configuration variables that refer
to on aobject cache type.
This is not a breaking change since ParsoidCacheConfig was only
introduced recently and is not in used in WMF config nor present in any
release.
This is a Follow-up to Ic67dc43ed9843810e4b180127f9a3bb7608f7608.
Change-Id: I9e61a6f94ec8bf1716c7d735f9bb17af4461fc9c
Cache the parsoid outputs only if a certain time is exceeded on
parse and consider the parse operation within this time limit as
not expensive per that wiki and not cache the parsoid output at all.
Bug: T308588
Change-Id: I7793b77feab13400ccd04343e7878ad701f5e6a7
Fix notice on PHP 7.4+ when the wordmark is false. It is false on the
beta cluster and Mustache doesn't mind if it is false. Update docs.
Use !empty($x) as a shortcut for isset($x) && $x in two nearby places.
Bug: T310767
Change-Id: Ie33f8edf075f1216881428ec6aa29cae1dac4e64
This introduces the ParsoidOutputStash config setting, which defines the
storage backend and cache duration. The storage backend name refers to
an entry in the ObjectCache setting, and defaults to the main stash.
Bug: T267990
Bug: T309016
Change-Id: Ic67dc43ed9843810e4b180127f9a3bb7608f7608
When JSON support was introduced into ParserCache in 1.36, it was
controlled by a feature flag, $wgParserCacheUseJson. The feature flag
was "born deprecated" in 1.36. It can now be removed.
This means that ParserCache will always store entries as JSON.
Support for reading old non-JSON entries remains intact.
This is needed when updating wikis from a version older than 1.36
to the current version.
Change-Id: Id04e42bfb458d98414bac50e0d6c505e8878e5c0
Previously, each of the four derived config schema files had to be
regenerated using a separate maintenance script. This change simplifies
regeneration by combining all for scripts into a single command that can
be used to regenerate all relevant files after changing
MainConfigSchema.
Change-Id: I7d38d8a4aede60475c4bdd0053d2e10e298b9843
Move config defaults to ResourceLoader class, so that the defaults
reside within the component responsibility, and for future standalone
use and unit testing with the same set of defaults.
Bug: T32956
Change-Id: I4a268e11686e526c4377542d45e198a72e57f182
This would be useful in cases that lots of edits happen at the same time
and this would reduce the time waiting to get the row lock.
Bug: T306589
Change-Id: I3b869e3b85dfd66575390ef4247f2f81f19c878e
