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
- How many rows are impacted? (run a query a week after change) << see results of queries in T299104#7746154 and T299104#7761220
- 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
- Write the script if needed.
- generic core patch (should be refactored for vector but currently generalized enough atm)
- script for centralauth to update global preferences (combined with generic patch using --db flag
- script for updating vector specific skin preferences (refactor of generic core patch) >> moved patch to WikimediaMaintenance extension
- Document on the team page how to do these sorts of migrations. >> https://www.mediawiki.org/wiki/Readers/Web/Maintenance_Scripts
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:
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/
- dry run is the default when running the script without the --commit flag -- this allows us to get a sense of affected rows for updates and inserts
- To run on a wiki as a dry run:
php extensions/WikimediaMaintenance/T299104.php
- To dry run on a wiki with inserts, use --insert option:
php extensions/WikimediaMaintenance/T299104.php --insert
- To actually run the database updates, add --commit option
php extensions/WikimediaMaintenance/T299104.php --commit
- To actually run the database updates with inserts, add --commit and --insert options
php extensions/WikimediaMaintenance/T299104.php --insert --commit
- To update global preferences as a dry run:
php extensions/WikimediaMaintenance/T299104.php --global
- To actually run the database updates for global preferences, add --commit option
php extensions/WikimediaMaintenance/T299104.php --commit --global
