Change Details

`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](https://www.mediawiki.org/wiki/Manual:$wgConditionalUserOptions). This was introduced in {T191888}. #popups 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 == Rollback plan - What is the rollback plan in production for this task if something goes wrong?

`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](https://www.mediawiki.org/wiki/Manual:$wgConditionalUserOptions). This was introduced in {T191888}. #popups 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 == 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

`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](https://www.mediawiki.org/wiki/Manual:$wgConditionalUserOptions). This was introduced in {T191888}. #popups 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 == Rollback plan - What is the rollback plan in production for this task if something goes wrong? 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