popups creates one property (and on three Wikivoyages, two properties) for each newly registered user, unconditionally. This is an antipattern that can be avoided via conditional user options. This was introduced in T191888: Change page previews configuration for opt-in accounts.
Page-Previews extension should be updated to make use of conditional defaults, instead of inserting additional rows into the database.
Acceptance criteria
- Existing users should get Popups disabled (e.g. before a certain date)
- New users should get Popups enabled (e.g. created after a certain date)
- Date to use should correspond to the date we updated mediawiki config in T197719
Requirement
Ensure that the Popups extension uses conditional user defaults for new and existing users to prevent database bloat.
BDD
Feature: Conditional User Defaults for Popups Extension
Scenario: Disable popups for existing users before a certain date
Given an existing user created before the cutoff date
When the user views the preferences page
Then the popups feature should be disabled by default
Scenario: Enable popups for new users after a certain date
Given a new user created after the cutoff date
When the user views the preferences page
Then the popups feature should be enabled by defaultTest Steps
Test Case 1: Disable Popups for Existing Users Before Cutoff Date
- On the beta cluster, go to Special:Preferences for an existing user created before the cutoff date.
- Ensure the "Enable page previews" option is unchecked.
- AC1: Confirm that the popups feature is disabled by default.
Test Case 2: Enable Popups for New Users After Cutoff Date
- On the beta cluster, create a new user account.
- Go to Special:Preferences for the new user.
- Ensure the "Enable page previews" option is checked.
- AC2: Confirm that the popups feature is enabled by default.
QA
On beta cluster
- On Special:Preferences make sure you have ticked "Enable page previews (get quick previews of a topic while reading a page)"
- Hover over links on https://en.wikipedia.beta.wmflabs.org/w/index.php?title=Special:WhatLinksHere/Dog and confirm they show a page preview.
Rollback plan
Since we've broken this change up into two patches (not including cleanup), it should be relatively safe to roll back. If the config patch needs to be rolled back, we will return to the current state. Once the config patch is deployed, provided we wait enough time to ensure it will stay in prod, we can deploy the patch to remove the old manual logic - if this needs to be rolled back, we will return to the intermediate state, where the database is being unnecessarily populated, but nothing strictly bad is happening. Once both patches are deployed we should again wait a bit, but then the cleanup patch is similarly revertible
QA Results - Beta
| AC | Status | Details |
|---|---|---|
| 1 | ✅ | T364347#9851663 |
| 2 | ✅ | T364347#9851663 |
QA Results - PROD
| AC | Status | Details |
|---|---|---|
| 1 | ⬜ | T364347#9886482 per T364347#9886511 |
| 2 | ✅ | T364347#9886482 |
