One more step in gradually replacing uses of ParsoidOutputAccess. This
one was pretty easy, as ParsoidOutputAccess was pretty much directly
calling ParserOutputAccess when provided with a ExistingPageRecord
and RevisionRecord.
Bug: T367074
Change-Id: I96161a64952e1809c0aec773d5a3dd4c71105657
Why:
- We want to distinguish temp account creation being enabled from a
configuration state where MediaWiki knows about temp accounts
existing (and can identify and manage them accordingly) while temp
account creation is disabled
What:
- Introduce a 'known' configuration flag to TempUserConfig
- If 'enabled' is set to true, then 'known' is automatically overridden
to true
- If an administrator wishes to disable temp account creation after
temporary accounts have been created, the administrator should set
'enabled=false' and 'known=true'
Co-authored-by: Tchanders <thalia.e.chan@googlemail.com>
Co-authored-by: Kosta Harlan <kharlan@wikimedia.org>
Bug: T356524
Change-Id: I4ce534a847461230f7fa276a565bdc1d6c9857e1
Special:RestSandbox presents a Swagger-UI interface for exploring REST APIs. The available APIs can be configured using RestSandboxSpecs.
For now, the default is to support no APIs, so the feature is disabled in production. In the future, it would make sense to expose the wiki's own REST API per default. The corresponding entry in $wgRestSandboxSpecs in LocalSettings.php would look like this:
'mw' => [
'url' => $wgScriptPath . '/rest.php/',
'name' => 'MediaWiki REST API',
]
Note that the spec URL may still change.
To also explore the endpoints exposed through RESTbase, we might add:
'wmf-restbase' => [
'url' => $wgServer . '/api/rest_v1/',
'name' => 'Wikimedia RESTbase API',
]
Similarly, we could expose a spec for endpoints on api.wikimedia.org, which could then be explored using the new special page.
NOTE: This adds a dependency on the swagger-ui npm library. See T325558 for the security review.
Bug: T362006
Change-Id: I1dd5ed82680a28f9c15136b446a2de0398525061
The criteria for doing so have now been met:
* PHP 8.1+ is now the documented minimum, and the 1.42 branch already
enforces this in PHPVersionCheck. (T359868)
* OpenSSL support is also now required. (e4127e5864)
As stated in AbstractPbkdf2Password::canUseOpenSSL(), the version check
is no longer needed because PHP 8.1 requires OpenSSL >= 1.0.2. While the
the master branch may still work on PHP 7.4 for now, it is unlikely that
a site using it would still have a version of OpenSSL older than 1.0.1f.
(For example, WMF stopped using Ubuntu 14.04 "Trusty", which has exactly
that minimum version of OpenSSL, once Canonical started charging for
security updates in 2019.)
The reasons for the version check were:
* Old versions of OpenSSL appeared to perform at least as well as PHP
for reasonably long passwords (up to 128 bytes for SHA-512 hashes);
however, they had the same DoS issue that our own implementation for
PHP 5.3 had (see T64685). hash_pbkdf2() never had that problem.
* If PHP were to incorporate the major optimization of hashing the HMAC
key blocks only once, then the old OpenSSL versions would actually be
slower. So far, this has not happened.
Change-Id: I47eb1aabf3d0ae4792624f9ba1c392880d52d0b7
- Add a disabled by default feature flag 'EnableProtectionIndicators'
- When the config flag is enabled, show a lock indicator at the top
of the page.
- The lock icon should be overridable by the content of the page
- The indicator has a predictable ID which could be potentially used
to style the icon using the onwiki Common.css file.
- The lock icon by default links to https://www.mediawiki.org/wiki/Help:Protection. However
this link can be customized per wiki per protection level using a
empty message (for example: `protection-sysop-helppage`)
Bug: T12347
Change-Id: I3e36d98edfe54a9c138b1fe8e5057e107ded281b
The `supportsContentModel` method is really querying Parsoid for the
set of content models it supports, so it makes sense to put it in the
Parsoid-specific SiteConfig service.
This is part of the work to deprecate and remove ParsoidOutputAccess.
Change-Id: I81eb2df8cef93ede95361a4e03185b3d58e5b84b
This adds MediaWiki\Watchlist namespace to the classes of watchlist
directory and adds deprecation notice since 1.43 to the just created
unnamespaced aliases of the classes.
Bug: T353458
Change-Id: I4234f8fe62bb3bde6f5271c7ba31a2420b0f4b90
This adds MediaWiki\Content namespace to FallbackContent
and FallbackContentHandler and declares the unnamespaced version
as deprecated since version 1.43.
Bug: T353458
Change-Id: I3ee80aea379788b71539cc1c7a4ec216b753e042
This patch introduces a namespace declaration for the
MediaWiki\Content to JsonContentHandler and establishes a class
alias marked as deprecated since version 1.43.
Bug: T353458
Change-Id: Ia4ba6d3eddcb7b3f3d9f41a5ff80f724dbd01b22
This patch introduces a namespace declaration for the
MediaWiki\RCFeed to UDPRCFeedEngine and establishes a class
alias marked as deprecated since version 1.43.
Bug: T353458
Change-Id: I27437c2417984f21e29237b011add20cad9f4389
This patch introduces a namespace declaration for the
MediaWiki\Content to TextContentHandler and establishes a class
alias marked as deprecated since version 1.43.
Bug: T353458
Change-Id: I2c72dacf28ee72fb70b15acdd81d0eb717ea949a
This patch introduces a namespace declaration for the
Wikimedia\Watchlist to ActivityUpdateJob and establishes a class
alias marked as deprecated since version 1.43.
Bug: T353458
Change-Id: I34342bb01c8f6c9657f1b2f05de1de64a107665f
This patch introduces a namespace declaration for the
Wikimedia\RCFeed to RedisPubSubFeedEngine and establishes a class
alias marked as deprecated since version 1.43.
Bug: T353458
Change-Id: If5b8a0b1f957e46f29907711079389fe543941d0
This patch introduces a namespace declaration for the
MediaWiki\Content to CssContentHandler and establishes a class
alias marked as deprecated since version 1.43.
Bug: T353458
Change-Id: I5504c21b4fabd6ce82c4dac37aacd1c74462c41b
This patch introduces a namespace declaration for the
MediaWiki\Content to JavaScriptContentHandler and establishes a class
alias marked as deprecated since version 1.43.
Bug: T353458
Change-Id: Ic30789d4e80a27004b6bc3b3ba891a7332a5e1ba
This patch introduces a namespace declaration for the
MediaWiki\RenameUser to RenameUserJob and establishes a class
alias marked as deprecated since version 1.43.
Bug: T353458
Change-Id: Ibf7d6d54e0047c6c298c02926d8a811d26f6361c
This patch introduces a namespace declaration for the
MediaWiki\Watchlist to WatchlistExpiryJob and establishes a class
alias marked as deprecated since version 1.43.
Bug: T353458
Change-Id: Ia0a85c9d7550edc972ea512606dfcf272c71a6cd
* Deprecate and stop using $wgBlockTargetMigrationStage. Remove
block_target migration code.
* Make the $schema parameters to DatabaseBlockStore methods default to
SCHEMA_BLOCK. Avoid passing these parameters where possible.
* Remove cleanupBlocks.php
* Deprecate DatabaseBlock static methods which try to present the old
schema for b/c.
Bug: T362133
Change-Id: I845bad8cc09a4528fef46a6f9d490ebdec881d99
Migrate from ipblocks to block/block_target and drop the ipblocks
table. Update tests.
In PostgresUpdater, change some schema update functions to skip field
updates if the table doesn't exist, by analogy with
DatabaseUpdater::modifyField.
Bug: T346293
Change-Id: Icf91b35f7f729cead7c800429653eb30731762a1
Modules group together endpoints by a shared prefix. The idea is that each module has its own version and can generated self-contained self-documentation. This allows clients to have clear expectations about the endpoints of each module, no matter what wiki they are accessing. So far, each wiki may be exposing a different set of endpoints, with no way to provide a spec that describes that set of endpoints in a way that would be consistent across wikis and stable over time.
Bug: T362480
Change-Id: Iebcde4645d472d27eee5a30adb6eee12cc7d046b
Legacy parser can now output headings using a more accessible markup,
which is also identical to the markup used by the Parsoid parser.
Changes to client-side JS and CSS necessary to support the new markup
have already been merged in earlier commits.
includes/skins/Skin.php
includes/ServiceWiring.php
* Define a new skin option, 'supportsMwHeading', which can be used
to toggle the new markup per-skin.
* Update the built-in fallback skin to enable it. This affects the
output in parser tests.
docs/config-schema.yaml
includes/config-schema.php
includes/config-vars.php
includes/MainConfigNames.php
includes/MainConfigSchema.php
* Add a new configuration setting, 'ParserEnableLegacyHeadingDOM',
which can be used to toggle the new markup per-site.
includes/OutputTransform/Stages/HandleSectionLinks.php
* Output new heading HTML for skins that enabled the option.
tests/*
* Duplicate parser tests that cover heading generation to cover both
new and old markup. Update other parser tests to use new markup.
* Add some unit and integration tests for the behavior of the skin
option and some parser tests for edge cases of the new markup.
Bug: T13555
Change-Id: I1180169a8e83af834c2984ba16089e6277f2a8dd
openssl provides the proper password hashing algorithm, so it is needed
in order to have safe and efficent password hashing.
Change-Id: I61498275c7f7cf19787f0aee50dc4884c57b82b2
According to the dictionary, "per" (or more conventionally "as per")
means "according to". Refer OED "per" sense II.3.a. For example:
"No value was passed, so return null, as per default".
In this sentence, we are not specifying the default, we are referring
to the default. This correct usage of "per default" was used nowhere
in MediaWiki core as far as I can see.
Instead we have "per default" being used to mean "by default", that is,
giving the value to use when no explicit value was specified.
In OED, the phrase "by default" is blessed with its own section just
for computing usage:
"P.1.e. Computing. As an option or setting adopted automatically by a
computer program whenever an alternative is not specified by the user
or programmer. Cf. sense I.7a."
There are highly similar pre-computing usages of the same phrase,
whereas the phrase "per default" is not mentioned.
As a matter of style, I think "per default" should not be used even
when it is strictly correct, since the common incorrect usage makes it
ambiguous and misleading.
Change-Id: Ibcccc65ead864d082677b472b34ff32ff41c60ae
Production is read new almost everywhere, mediawiki core should reflect
that as well.
Bug: T299947
Change-Id: I8f05c4d7026394205bfc54b68dc725392852ae2a
Why:
- We don't want to allow unlimited acquisition of temp account names.
These should be rate limited in similar way to how we limit the
creation of temp accounts
What:
- Provide a TempAccountNameAcquisitionThrottle, and use it in the
acquireName() method
- Set a default that is 10 times the limit of
TempAccountNameCreationThrottle
Depends-On: If660aad1d0f04f366414084aff3f88484a19d416
Bug: T343101
Change-Id: I99d5973498a89ac227847de5837c0a8e895c28fb
Why:
* The default value of wgAutoCreateTempUser has not changed since
the decision to use a different prefix for temporary accounts
(T332805).
* The default needs to be updated to reduce the number of overrides
in operations/mediawiki-config and also to make the development
experience more consistent with what is happening on WMF
production.
What:
* Update the wgAutoCreateTempUser default in the following ways:
** Set expireAfterDays as 365
** Set notifyBeforeExpirationDays as 10
** Set genPattern and reservedPattern to '~$1'
** Set matchPattern to null, which will mean that the genPattern
is used as the value.
* Update RealTempUserConfig::getPlaceholderName to add the year to
the placeholder name so that if the match pattern includes the
first digit of the year, then the placeholder name still is
considered a valid temporary account username.
* Replace modifications of the wgAutoCreateTempUser config in
integration tests with a use of the TempUserTestTrait to make
the code cleaner and make it easier to find tests that relies on
the values in wgAutoCreateTempUser.
* Update multiple tests to handle the new defaults for the config.
Bug: T359335
Change-Id: Ifa5a0123cd915bdb7c87e473c51fb93321622f12
Adds two new conditional user option default conditions CUDCOND_ANON and
CUDCOND_NAMED, for the purpose of allowing the specification of a
separate default user option for logged-out users. We're taking two
different approaches to the targeting of logged-out users (anon vs
named) because of the temporary users project - anon will not include
temporary users while named will allow us to target only fully created
user accounts. This will be ultimately be used for the rollout of the
reading accessibility settings menu
Bug: T360098
Change-Id: I316d231330159770f05234dd2f5fdb7d07531002
With this change, when async uploads are enabled, upload-by-url
will spawn a job and a form with a button to check the status of the
process is shown to the user.
In the process, add processing of warnings in the remote jobs spawned by
the API or the Special page. This is done by adding checks to
UploadJobTrait::verifyUpload. In order to manage warnings serialized in
the job status, a method to unserialize the result of
UploadBase::makeWarningsSerializable.
Things that we might want to fix:
* The form's UI is abysmal, we should probably use Codex
* While it's not a huge deal, I'd like to figure out why I need to
purge the page cache if I want the file to show up. And more
interestingly, why this doesn't happen when uploading via the API
Bug: T295007
Bug: T118887
Change-Id: I49181d93901f064815808380285fc4abae755341
Described as "Evil hack for mobile :(", this config variable had been
overridden in the MobileFrontend extension for some time, but this has
been removed last year in Icb1711a0cef828dda0d99b8a7c7963bc409816c9.
Since it was introduced, most HTMLForms using the 'table' format have
been reworked to use 'ooui' (or 'codex', these days), so the hack is
no longer needed.
We recently removed $wgUseMediaWikiUIEverywhere for similar reasons
in aa7eeeeef9 / be135c0fc0.
Change-Id: Id507c0dc5a1c1cfb9737073bae97b14badc30a54
ObjectCache is already doing a lot of factory pattern logic like
creating instances of the various BagOStuff, this should really be
the responsibility of the factory servicet.
This patch introduces a proper factory (ObjectCacheFactory) to handle
the responsibility of creating various instances of BagOStuff. Since
`newFromParams()` is a static function that gets passed in configuration
of $wgObjectCaches, that can stay that way (to keep supporting how we do
this in prod today).
Technical Breaking Change: `ObjectCache::makeLocalServerCache()` now has
a parameter and requires it but there are no callers of this method outside
MW core hence it is safe to change (and this patch update all callers) to
work correctly. Cache prefix is gotten from global state because sometimes
at this stage, the services container is not available.
Bug: T358346
Change-Id: I3179a387486377c6a575d173f39f82870c49c321
Add a temporary feature flag that is going to be covering the work
around implementing a logout confirmation.
Bug: T357484
Change-Id: I3ee8f52976cb956e24f32115c02903c5c4f358c3
The MainPageIsDomainRoot setting has been supported since 1.34, time to
remove the "experimental" marker.
Note that this setting was never marked as experimental in the documentation: <https://www.mediawiki.org/wiki/Manual:$wgMainPageIsDomainRoot>. It seems likely that it is in use on many third party wikis already.
Change-Id: I02d2b2d4569f505d5dcc59ae60bc9f64deee064c
Allow extensions with very special modules that can't be called in a
testing environment to skip ResourcesTest::testRespond().
Needed by If1186797fd047d4f for ext.wikisource.OCR.
Change-Id: Id02915d9633c2d8209d2ff2e60f6748095ec10fe
Why:
- The pathway to creating a regular account is different from that of a
temporary account. It makes sense to rate limiting creation of these
two types of accounts at different rates.
What:
- Add a TempAccountCreationThrottle config with a restrictive default
that matches the existing production configuration of
AccountCreationThrottle (6 creations per day)
- Update resetAuthenticationThrottle.php to support resetting the temp
account creation throttle
- For now, not adding an equivalent hook for account creation throttle's
ExemptFromAccountCreationThrottle
Bug: T357777
Change-Id: Ibf36ac96f717107bace6f0a3326f79ed129a1dfe
The TranslationAliasesDirs configuration allows defining translatable
aliases in JSON files. The value should be a name or names of folders
that contains files that have localized aliases. Each language should
have a separate file.
Currently, it supports defining special page aliases but in the
future can be extended to support magic words and namespace aliases.
The patch adds a script: ConvertExtensionsMessagesToTranslationAlias
that can be used to convert existing ExtensionMessagesFiles to the new
format.
Bug: T89947
Change-Id: Ief16a48a8dc8742854f67301791aa2a0b0531116
Introduce a temporary feature flag that will be used to display
Special:Block UI in Codex.
Bug: T358153
Change-Id: I74bc90af986ac2f429a952a19b6edf4fb02c5618
After the deployment of the updated mediawiki.cookie module, the
configuration variable can be safely removed.
Bug: T344791
Change-Id: Idf3b3ef521ef2ac368c3f575f99bf4c6da7baa82
Not to be confused with $wgOpenSearchTemplates (plural)
Soft-deprecated since 1.25 and hard-deprecated since at least
I9776d11d4e2d184 (1.39).
Not set in production.
Change-Id: I6a95b9e0e2b74bb44d51c375a62886761ec9ea88
This is used to (among other things) detect lang tags in multilingual
SVGs. Users have complained that lang tags are often missed in large
SVG files.
The cut-off is used for two things during upload:
* Run some (simple) regexes to detect <?xml header
* Use XMLReader (with entity substitution enabled!) to look for specific tags.
The first check doesn't make sense to use a configurable cut off. Change
it to look at the first 4096 bytes only. The <?xml header is required to be
the first thing in the file other than BOM, so this should be more than
sufficient. XML parsers give a fatal error if there is whitespace before
the <?xml declaration.
It seems unlikely to be problematic to use XMLReader on up to 5MB of the file,
since that is a "pull" XML parser, and won't load the entire file at once.
The code that cuts off the SVG at the 5MB mark likely uses more memory
than parsing the file does. In fact, we separately use XMLReader to do
security checks with no such cut-off, so potentially it could even make sense
to remove the cut-off entirely, since clearly parsing the full file is not
causing problems.
Bug: T270889
Change-Id: I7350918647d92c40934a7c86e906b6bfb8a40ada
* Deprecate the wgUseSameSiteLegacyCookies configuration variable and
imply false (the previous default).
* Deprecate WebRequest::getCrossSiteCookie(), which was introduced to
support this feature.
* Ignore the sameSiteLegacy option if it is passed to
WebResponse::setCookie() or mediawiki.cookie.set(). The configuration
variable can't be removed until the after the JS change is deployed.
Bug: T344791
Change-Id: I30392ebc02809bc6b6ee2070d3e468e48d5d1fae
Why:
* The wgEnablePartialActionBlocks config is marked as unstable,
but also as to be removed before 1.38.
* This is no longer the case as this config is present in 1.42 and
as such this should be removed and instead still indicate this
is unstable without listing a release version for this config.
What:
* Reword the @unstable tag for the wgEnablePartialActionBlocks
to no longer reference a specific release version.
Bug: T280531
Change-Id: I317cd07c42aa59c6a45bf7403fdc79a363880bb5
MediaWiki UI has never really made it out of beta before being
deprecated. Legacy code using plain HTML forms doesn't need it;
new code can be written using Codex.
Bug: T182050
Change-Id: Ib9966bc6a4a94f771cb99a5aa52fb6a1dc826ca5
Soft-deprecated since 1.26 and hard-deprecated since at least
I9776d11d4e2d184 (1.39).
Not set in production.
Change-Id: I55e4569c5a40f77a719bc7ab1924eaa706e0da53
Soft-deprecated since 1.35 and hard-deprecated since at least
I9776d11d4e2d184 (1.39).
Not set in production.
Change-Id: I68b68ffcdff22daafad34c186d1cc609dcecbf32
Soft-deprecated since 1.33 and hard-deprecated since at least
I9776d11d4e2d184 (1.39). It's already noop in the code.
Not set in production.
Change-Id: I5895bc4dae9620d53c37188662e21bf01ae7bd85
Soft-deprecated since 1.37 and hard-deprecated since at least
I9776d11d4e2d184 (1.39)
Not set in production.
Change-Id: I0b25e89d1652dfa697ab1176a1e2b6ca3163bdab
It has been deprecated since 1.35, hard deprecated since at least I9776d11d4e2d184
No grep result in wmf-config
Change-Id: I2c67bab3e3212f25a0cbce7301f5e32a082f76da
Add a user preference to allow the user to enable or disable
EditRecovery.
Set the default as disabled.
Bug: T350653
Change-Id: Ibbb59eb84f1dd0b40f9576e048f2ac76044f9014
Use ObjectFactory specifications instead of class names in
$wgLogActionHandlers, like in most other places. Class name
support is retained for B/C.
Also remove old LogPage code that assumed $wgLogActionsHandlers
is an array of callables. This is how $wgLogActionsHandlers was
defined in b6d72cfeb2, but then
4ac56c2466 redefined it to an
array of classnames (and I6846ce0 adjusted the documentation),
and the old functionality has been broken since.
Make LogFormatter::__construct() public so subclasses can be
created in the service wiring.
Technically this is a breaking change since there is no
guarantee existing formatter classes are publicly creatable,
but there is no way to issue a deprecation warning about that,
and it isn't really covered by the stable interface policy.
All non-public constructors found by codesearch are fixed in
companion patches.
Bug: T54220
Change-Id: I72427a4b3f4be1c3c1eb3522a8b58fe9445a3397
Depends-On: Ie691e8d59141f696619dce8f756645c45a3e943a
Depends-On: I41562247d51f4f9fe8dafed37ba2ad81c881d99d
Why:
* There is a need to update the generation and match pattern on
WMF wikis to a new format that includes the year and starts with
`~`. As such, the 'matchPattern' key needs to be updated.
* Removing the old 'matchPattern' from the wgAutoCreateTempUser
config currently leaves existing temporary accounts as no longer
recongnised as temporary accounts.
* Instead, the 'matchPattern' needs to be able to take an array of
string patterns so that old patterns can still be used for matching.
What:
* Update the MainConfigSchama to indicate that 'matchPattern' in the
wgAutoCreateTempUser config can be an array of strings.
* Add TempUserConfig::getMatchPatterns and deprecate TempUserConfig::
getMatchPattern. This is needed because ::getMatchPattern was typed
to only ever return one Pattern, which is no longer the case with this
config change.
* Update the RealTempUserConfig to support multiple patterns defined in
the 'matchPattern' key. The RealTempUserConfig::getMatchPattern method
returns the pattern or first pattern if multiple are defined to allow
time for existing usages of this deprecated method to be updated.
* Update the RealTempUserConfig to rely on other methods instead of checking
object property values where possible (e.g. use ::isEnabled instead of
checking $this->enabled) to allow easier unit testing.
* Update UserSelectQueryBuilder and ChangesListSpecialPage to use TempUserConfig
::getMatchPatterns instead of ::getMatchPattern.
* Update mediawiki.util/util.js to be able to parse the 'matchPattern' value
when it is an array of strings.
* Update maintenance/userOptions.php to use ::getMatchPatterns instead of
::getMatchPattern.
* Add and update unit and integration tests for the new code, as well as
expanding coverage over existing code that was indirectly affected.
Bug: T354619
Change-Id: I3763daefe4dc7c76370bd934fb20452591c9c762
User options saved to the database and retrieved get converted
to strings, but defaults and set but not yet saved vaues don't.
This behavior can be confusing.
When a value equal to the default is set for a given user, that
value won't be written to the database; defaults are represented
by the lack of a database row. This behavior can also be
confusing.
Update the phpdoc of some user preferences related methods and
variables to make these things clearer.
Change-Id: I32a18b30f007c97015e6d641379ce60ab6ac7ed7
INSERT IGNORE when inserting NULL into a non-nullable field will succeed
with a warning on MySQL but fail on PostgreSQL. In any case, it's
probably harmful and unintended. But to check the error code of MySQL
warnings, you need to query the server with SHOW WARNINGS, so there is a
performance cost.
So, add a configuration variable which, when enabled, checks warnings
after INSERT to see if there were any null type constraint errors. Set
it to true in DevelopmentSettings.php and TestSetup.php.
Change-Id: I5e47e2d3cc7e0f804036e11b512b1e3b76804432
Follows-up I8518e0488 (9c02258a04).
Instead of documenting how to compute the number to manually verify
it, use the expression directly. This should make it significantly
easier to understand, verify, and modify.
Noteworthy:
* Language.php, I kept 31_556_952 as-is because the
calculation would otherwise involve a float. It also has the benefit
of allowing the long durations to build upon that as a given number.
* SqlBlobStore.php, remove this irrelevant default value as it is
unreachable. The only call to new SqlBlobStore is BlobStoreFactory,
which always calls setCacheExpiry. For back-compat and to keep
tests as-is, move to re-used constant between class and config.
Change-Id: I86b034883bd7efdf93b8365b43178af826f1c703
* Log a message when thumbnailing is attempted but disableLocalTransform
is set in configuration. There is already a similar log entry in
thumb.php but it was missing for other callers.
* Update the config docs.
Change-Id: If4c02b831989e6183b72384e676cddeab1dcf41e
Why:
Sometimes, it is necessary to have different behavior
for newly registered and existing users. For example,
this happens in the Echo or GrowthExperiments extensions.
As of now, this behavior is implemented by inserting
user_properties rows in onLocalUserCreated.
Over time, this results in a singificant amount of rows
inserted, which contributes to the user_properties table bloat,
which is already overly large (cf. T54777). This patch makes it
possible to remove such rows by supporting conditional defaults
for user properties.
What:
Add support for conditional defaults of user properties. This can be
configured via `ConditionalUserOptions` config option.
Bug: T321527
Change-Id: I1549c3137e66801c85e03e46427e27da333d68e2
Why:
* Part of a temporary user name is generated from an index that
increments, which is stored in the database.
* As specified in T345855, the index will be restarted each year.
* Also specified in T345855, the year will be included in
generated temporary user names.
What:
* Since the year must be included in the name in order to avoid
naming conflicts if the index is restarted each year, both are
implemented together and controlled by a single config.
* Add a new config option that, when true, restarts the name
generation index at the start of each year and add the year into
the user name: $wgAutoCreateTempUser['serialProvider']['useYear']
* Add a uas_year column to the user_autocreate_serial table, which
is unique in combination with uas_shard, so the index can be
stored for each shard/year combination.
* The year is added into the username just after the prefix, as
specified in T345855. This is based on research that having the
year near the start of the name aids understanding that the
names are not IP addresses. The position of the year within the
name is therefore not configurable (though whether to include
it is). See T345855 for the research.
Bug: T349494
Bug: T349501
Depends-On: I6b3c640a4e74f52fd4a4f46de5a2cbe80fe3b665
Change-Id: If51acb3f4efa361ce36d919c862a52501a5a7d24
