Change Details

Implement what came out of the investigation documented in {T233109}: > Separate user preferences for Page Previews and Reference Previews. This will make it possible for users to have both features disabled, both enabled, or one enabled and the other disabled. Acceptance criteria: [] The existing setting on the "Appearance" tab should continue to talk about "Page previews" only, not about "popups". [] The new setting should say something like "enable Reference Previews". [] The new setting should be directly after the existing one. [] As long as we are in Beta, the new setting needs to stay on the Beta tab. The new setting on the Appearance tab should already be implemented, but hidden then. [] The text on the Beta tab needs to be changed: Remove the sentence about "Page Previews must be enabled as well". [] The existing "Page previews" setting can not disable the extension any more, but only one of the popup types. To achieve this, the check must be moved from the backend (PopupsContext.php) to the frontend (probably in src/index.js). [] The module should not be loaded when all popup types are disabled. To do: [] The workflow for anonymous users is entirely undefined as of now! It might be that reference previews are always on for anonymous users, or disabled together with page previews. [] Talk to UX and/or the WMF team formerly working on #page-previews and ask if it is ok to turn the existing "Enable/Disable" radio buttons into a single checkbox. (Note from @thiemowmde: I remember asking the devs about this. They said this was intentional to give the user something with much more surface area, so it feels much more like a deliberate decision made by the user.) [] Check if we have a ticket to remove all BetaFeature code when it's not needed any more. [] Check if we have a ticket to remove the PopupsReferencePreviews feature flag when it's not needed any more. This is especially relevant because this is exposed in JavaScript, and does waste a tiny little bit of our users resources.

Implement what came out of the investigation documented in {T233109}: > Separate user preferences for Page Previews and Reference Previews. This will make it possible for users to have both features disabled, both enabled, or one enabled and the other disabled. Acceptance criteria: [x] The existing setting on the "Appearance" tab should continue to talk about "Page previews" only, not about "popups". [x] The new setting should say something like "enable Reference Previews". [x] The new setting should be directly after the existing one. [x] As long as we are in Beta, the new setting needs to stay on the Beta tab. The new setting on the Appearance tab should already be implemented, but hidden then. [x] The text on the Beta tab needs to be changed: Remove the sentence about "Page Previews must be enabled as well". [x] The existing "Page previews" setting can not disable the extension any more, but only one of the popup types. To achieve this, the check must be moved from the backend (PopupsContext.php) to the frontend (probably in src/index.js). [x] The module should not be loaded when all popup types are disabled. To do: [x] T235737 The workflow for anonymous users is entirely undefined as of now! It might be that reference previews are always on for anonymous users, or disabled together with page previews. [] Talk to UX and/or the WMF team formerly working on #page-previews and ask if it is ok to turn the existing "Enable/Disable" radio buttons into a single checkbox. (Note from @thiemowmde: I remember asking the devs about this. They said this was intentional to give the user something with much more surface area, so it feels much more like a deliberate decision made by the user.) [] Check if we have a ticket to remove all BetaFeature code when it's not needed any more. [] Check if we have a ticket to remove the PopupsReferencePreviews feature flag when it's not needed any more. This is especially relevant because this is exposed in JavaScript, and does waste a tiny little bit of our users resources.

Implement what came out of the investigation documented in {T233109}: > Separate user preferences for Page Previews and Reference Previews. This will make it possible for users to have both features disabled, both enabled, or one enabled and the other disabled. Acceptance criteria: [x] The existing setting on the "Appearance" tab should continue to talk about "Page previews" only, not about "popups". [x] The new setting should say something like "enable Reference Previews". [x] The new setting should be directly after the existing one. [x] As long as we are in Beta, the new setting needs to stay on the Beta tab. The new setting on the Appearance tab should already be implemented, but hidden then. [x] The text on the Beta tab needs to be changed: Remove the sentence about "Page Previews must be enabled as well". [x] The existing "Page previews" setting can not disable the extension any more, but only one of the popup types. To achieve this, the check must be moved from the backend (PopupsContext.php) to the frontend (probably in src/index.js). [x] The module should not be loaded when all popup types are disabled. To do: []x] T235737 The workflow for anonymous users is entirely undefined as of now! It might be that reference previews are always on for anonymous users, or disabled together with page previews. [] Talk to UX and/or the WMF team formerly working on #page-previews and ask if it is ok to turn the existing "Enable/Disable" radio buttons into a single checkbox. (Note from @thiemowmde: I remember asking the devs about this. They said this was intentional to give the user something with much more surface area, so it feels much more like a deliberate decision made by the user.) [] Check if we have a ticket to remove all BetaFeature code when it's not needed any more. [] Check if we have a ticket to remove the PopupsReferencePreviews feature flag when it's not needed any more. This is especially relevant because this is exposed in JavaScript, and does waste a tiny little bit of our users resources.