> Note: It's possible that T212516 needs to be fixed before taking this on.
> Consider a feature branch to speed up development and encourage you to break this work into small progressive easily-reviewable chunks rather than one giant commit. Sync with whoever is working on T212216
== Background
more details in {T210653}, **please read** before starting this task. Note that the acceptance criteria in this task does not reflect the final version of the feature.
== Acceptance criteria
[] The entire AMC feature set is behind a feature flag that can be enabled/disabled on a per-wiki basis and is disabled by default
[] Toggle is on the mobile settings page for logged in users
[] For anonymous users, no toggle appears
[] The feature is available as a separate setting (not a part of beta)
[] When opting into the new mode using the toggle switch, there's no product need to reload the page (as currently the UI doesn't change in any visible way) but we may want to reload it given in future changes may happen. Developer should decide what makes the most sense here.
[] When a user opts in to the AMC mode we need to ensure it is logged and compatible with Schema:PrefUpdate in WikimediaEvents per T212516. Make sure it uses either the [[https://github.com/wikimedia/mediawiki-extensions-WikimediaEvents/blob/master/includes/WikimediaEventsHooks.php#L289 | WikimediaEventsHooks::onUserSaveOptions ]] hook or the API. Note that if we use and update the hook, we also get T212516 fixed for free!
= Open questions
[] FeaturesManager::isFeatureAvailableInContext will need to be updated to take a $user object and check the stored value of AMC. It's unclear if that needs to be part of this change or separated into a new task or the talk task (T212216)
== Mockup
{F27322644}
== Prototype & workflow
https://wikimedia.invisionapp.com/share/RNO2HHBPK7M#/screens/331909359_Enabling-Disabling
= Developer notes
Note: that the form currently works with and WITHOUT JavaScript
{F27637937}
The form is a standard POST form with the post handled in SpecialMobileOptions::submitSettingsForm
This will need to set a user preference when the user is logged in.
This preference is likely needed to be registered in Special:Preferences (although can be added as a hidden preference). See MFEnableMobilePreferences for how we're managing mobile preferences currently.
Note, in the case of opting into beta mode when logged in, the setting of the mode is handled in [[ https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/blob/master/includes/MobileContext.php#L272 | setMobileMode ]]. This code might be useful to look at.
The JS mode will be a little trickier.
That will need to inject a toggle box and HIDE the checkbox (see https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/blob/master/resources/mobile.special.mobileoptions.scripts/mobileoptions.js#L128 and implementation of beta toggle)
Make sure it's possible to tab between the controls as a proxy to check that the form is accessible.
Note: we wil NOT brand the experience like we do with the beta symbol (see screenshot).
{F27638009}
This was added to beta as we got lots of bug reports (screenshots) and didn't know what configuration the user was using so how to replicate, but will not be used in AMC as we are expected the UI changes to be much more obvious.
== Refactor opportunity
It is suggested that we move all setMobileBetaMode, isBetaGroupMember, all beta/stable constants from MobileContext into new class, something like MobileUserOptions, or MobileUserMode and keep all logic (reading/writing user options/cookies etc) there. It will be easier to maintain/rewrite this feature, plus if we decide to handle anons, the only place where changes will be required are Special::MobileOptions (for render and submit logic) and that new class. See related T144085 and T143189