The script contains an allow list of provider ids
to migrate.
When using the --dry-run option the script will
collect the provider/schema informed configuration
options and use the provider validator to check
for the config validity.
On standard run validity of the collected
configs is also checked and if passed, the new
configuration is stored in the wiki page informed
by the provider.
Note: config options showing as untouched are
most probably legacy options that have not
been removed from the wiki config. Consider
removing them.
Note: config options showing as missing are most
probably options that belong to a feature is not
enabled in the wiki. These need to be reviewed
when running the script.
GEHomepageManualAssignmentMentorsList
GEHomepageMentorsList
Bug: T359038
Depends-On: I1ec7d9f9b67c47955e94ad7f9bec5576bc6f9c8e
Change-Id: Ida92d0e94ae49cc768736fc29e129ca6bc6adf08
This now logs an error with the user id, so that we can follow-up on the
underlying issue. If that reveals that a user with no registration data
is valid, then this logging can be later removed as well.
Based on https://www.mediawiki.org/wiki/Manual:User_table#user_registration
the `registration` field should always have been set except for very old users.
Maybe we just need to run the maintenance script mentioned there for
another wiki.
Bug: T355344
Change-Id: I95494b0cd96e24fa1bab66bf843e5f927b5f9c16
If a username only consists of digits, then setting it as the key of an
array will set it as a _numeric_ key. MySQL/MariaDB in turn does some
strange type conversion when it receives a numeric value in a where
clause for a field that contains strings. That lead to the query for the
username `555` also returning the usernames `555_É_GAY`, `555éGAYSAÇO`,
and `555éViado`.
Bug: T355344
Change-Id: I9493d67c5cb5d6088723c64950f57ff6512ba528
Reduce the maintenance burden of needing to update the documentation
when the interface changes.
This is needed for T363358, which refactors some classes that build
Special:Contributions.
Bug: T364569
Change-Id: Ia14784908790dc2cfd1b65b738730f759c780642
In I05e1c6dc322939619855a690a55d07adcb6b55ae two
enum config options GEHelpPanelAskMentor and
GEHelpPanelHelpDeskPostOnTop. However GE code
still expects these options to be booleans.
Introduce a wrapper config reader that relies
on CommunityConfiguration WikiPage reader but maps
new values to old values. This is in order to keep
the config code intact for eventual roll backs of
the CommunityConfiguration extension/migration.
Bug: T364053
Change-Id: I279040fef9ebcb42d333096d6675b3051e4101ed
A spelling mistake was made for the property
GEHelpPanelHelpDeskPostOnTop. This is relevant
for migrating existing wiki configs to the new
config files structure without having to special
case this option.
Also rename the property associated messages.
Change-Id: Ibc61716ea5d7cecbe9dfdfa8ea41a75d84088512
Use TYPE_INTEGER for pressumably int values and
keep TYPE_NUMBER for float values.
Bug: T363733
Depends-On: Ida3964c0293c67766607dcf437b8d26892418459
Change-Id: Ie5c9523758b660674af4a751275d6820f73f6876
The field up_value is a varbinary and should be provided as string,
not all rdbms implicit converts int/strings
Change-Id: I3d016969559401ecc54bb27c192b66183d47345b
Immediately after merging the patch,
Special:CommunityConfiguration/GrowthSuggestedEdits will work,
but it will look very broken. This is because of T363477 and
T362098, which will make the form look (mostly) normally.
The form should now look like https://ctrlv.cz/1zNn, and
the config for the three structured tasks should work
as expected.
Bug: T360471
Depends-On: I6b6470ac05316f475660294740fecb4e35296229
Change-Id: I0a25dd94c5f88b2a887dc7879623dd9e3219e2c8
`GEHelpPanelLinks` is represented as associative arrays in
CC1.0, but in CC2.0, it is returned as a stdClass. Fix
that by adding a casing.
Also remedy PHP Warnings by renaming `label` to `text`,
which is expected in HelpPanel class. Otherwise,
the following notice would be displayed:
Warning: Undefined array key "text" in
/var/www/html/w/extensions/GrowthExperiments/includes/HelpPanel.php
on line 68.
Bug: T363459
Change-Id: I1507dcb6739cb22c5cf049d19b7e3bad8db2c0da
Add currently supported configuration options from
Help Panel settings. This is to facilitate the testing
of the namespaces control, T357708.
Unsupported options which are left out:
- "GEhelpPanelAskMentor" and "GEHelpPanelHelpDeskPostOnTop" which
require enumerations support, T362685.
Bug: T360472
Depends-On: I2d1e0796dbd1a521d8e930eeafbde61794f92150
Depends-On: I600347aec0baa403e2c96e02dc2d897954df2005
Change-Id: I6d2b4c8639f765909c21b1cae5a60b5f5898a647
- Add only "GEInfoboxTemplates" configuration option
which uses "PageTitles" Mediawiki definition from
community configuration.
Bug: T360471
Depends-On: I384eb017f41e665a43583aac2620157d94e61ffd
Change-Id: I752ea041632338a388770585fcf4f111e139782a
The handler needs the prefix to work, but it is incorrectly
labelled as optional. Fix that.
See I47aa1f3000833f7c6f572bbd262153b5b79aef38 as well.
Bug: T359652
Change-Id: Id216e1c0c6797e2b76a1bc9510877d416b5b9e06
The autocomments have the following format:
message-key:param1|param2|param...|paramN
Prior to this patch, we used explode( ':', $comment )
to parse the comment into the message key and param array.
However, this does not work if there is a colon in one
of the params.
Resolve this issue by using explode( ':', $comment, 2 ),
which only uses the first colon as a delimeter, and ignores
any other colons.
NOTE: The same problem will happen when using a pipe character.
This is less critical, as pipe is less commonly used (and it has
special meaning in wikitext already, so easier to explain). This
is left for a future discussion and/or fix.
Bug: T360846
Change-Id: I5d0974f4e2154ae41cce6629c8e1d19e166a2913
Mixing different binary boolean operators within an expression
without using parentheses to clarify precedence is not allowed (T358966)
Change-Id: I450a224552ac7ddb0c638afe8c16e4f1d9583c92
Why:
The Growth team works on the CommunityConfiguration extension,
which re-implements the ability for administrators to edit
MediaWiki configuration on-wiki in a different way.
This patch allows developers to switch from the GE-specific
implementation of community configuration (so-called CC1.0)
into the new dedicated implementation that CommunityConfiguration
represents.
The patch is meant to make GrowthExperiments stop use any of its
CC1.0 implementation if GEUseCommunityConfigurationExtension is true,
including the editing form.
Notes:
CommunityConfiguration expects client extensions to use a single
Config object (=the one provided by CommunityConfiguration)
for all config needs. This enables client extensions to seamlessly
switch between configurable and non-configurable fields (it is a matter
of changing the scmea), without having to review their usage across their
whole repository. To fully benefit from this expectation, we need to change
how we approach config within GrowthExperiments.
What:
* Introduce `GEUseCommunityConfigurationExtension` config flag, which
is false by default.
* Create `GrowthExperimentsCommunityConfig`, which either returns
the `GrowthExperimentsMultiConfig` service or the CommunityConfiguration
provided service, depending on the feature flag.
* Switch SpecialEditGrowthConfig's registration to a conditional one,
based on the feature flag value.
* Move two schemas from CommunityConfigurationExample to GrowthExperiments
Bug: T359124
Depends-On: If9db50b8ba8dc835a7d5e1c49de83e7ff2941c01
Change-Id: I2b6e3436c08100442baf4ed65582d0bc17fd449c
