When the new Vector skin is enabled, we have added code to make sure end users continue to get their preferred skins. This will allow us to remove the skin version code as we will no longer need to map old preferences to new preferences. This also means we can refactor the existing Vector code safely, separating legacy and modern more distinctly.
Previously the choice of Vector mode was made by consulting the user VectorSkinVersion preference
Now the choice of Vector is made by consulting the user VectorSkinVersion preference and the skin preference.
The switch means that many users will have database rows like so:
| skin | VectorSkinVersion
| vector | 2 |
These must all be replaced by
| skin | VectorSkinVersion
| vector-2012 | 2 |
These rows will only be corrected whenever a user saves a preference.
We may need to consider writing a script to fix these, or deciding it's not important to fix.
# TODO
[x] How many rows are impacted? (run a query a week after change) << see results of queries in T299104#7746154 and T299104#7761220
[x] Should we write a script to migrate these rows, or simply revert these users back to legacy Vector for manual correction? yes - we need 2 versions
[x] Write the script if needed.
[x] generic core patch (should be refactored for vector but currently generalized enough atm)
[] script for `centralauth` to update global preferences
[] script for updating vector specific skin preferences (refactor of generic core patch)
[] Document on the team page how to do these sorts of migrations.
# Developer notes
To check rows impacted, you'll need to ssh into one of the replicas (listed at https://wikitech.wikimedia.org/wiki/Analytics/Systems/MariaDB) and run a database query on the preferences table.
# Migrate script
Here is an example of a maintenance script that migrates preferences:
https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/MediaSearch/+/refs/changes/53/752653/3/maintenance/MigrateSearchPagePrefs.php?autodive=0
We'll need to write our own.
Executing the script would need to happen in a special deploy (out of scope for this ticket).
# QA steps
For the first iteration of the script, the following command should be run with the necessary options (these are required so validation will prevent running the script without any of the needed parameters and tell you which options are missing):
- ssh into the proper server
- make sure you are in the correct directory i.e. `/var/www/html/`
- there is a dry run option which can be run first to get a sense of how many rows will be affected i.e. `--dry`
```
php maintenance/UpdateUserPreferences.php --set-pref-name 'skin' --set-pref-value 'vector' --where-pref-name 'VectorSkinVersion' --where-pref-value '2' --new-value 'vector-2012' --dry
```
- the actual command that should be run to make the updates
```
php maintenance/UpdateUserPreferences.php --set-pref-name 'skin' --set-pref-value 'vector' --where-pref-name 'VectorSkinVersion' --where-pref-value '2' --new-value 'vector-2012'
```
for the CentralAuth database, here are the commands for dry run and actual respectively:
```
php maintenance/UpdateUserPreferences.php --set-pref-name 'skin' --set-pref-value 'vector' --where-pref-name 'VectorSkinVersion' --where-pref-value '2' --new-value 'vector-2012' --db centralauth --dry
```
```
php maintenance/UpdateUserPreferences.php --set-pref-name 'skin' --set-pref-value 'vector' --where-pref-name 'VectorSkinVersion' --where-pref-value '2' --new-value 'vector-2012' --db centralauth
```