Change Details

Follow up from full page editing spike: T328591 This task is to update our article view to allow for full page editing. We are going to lean on our current section wikitext editor flow, so design should consider how that currently works and document if any UI changes need to be made for full page editing. === Design notes === 1. Design: Add a place somewhere in our article view where a user can enter the entire the full page editor flow. 2. Design: Should any UI/copy/logic change in the existing editor when using in full-page mode? This includes any changes needed on initial modals (onboarding, edit notices, blocked messages), the standard flow screens (wikitext editor > preview > save screens), error messages when attempting to publish, and success message on article after successfully publishing. === Engineering notes === //Note: Basic prototype work is done in `full-page-editing` branch. Feel free to reference.// 1. Do some small code renaming to our SectionEditorViewController flow to allow for full page editing (like maybe rename "section" out of various places, since these code files will now support full page editing). 2. Do necessary changes to get full page editing mode working: - Make section ID optional when entering editing screens and pass in nil. - When fetching wikitext, remove section ID from API call so that full wikitext is fetched and loaded in editor. - When publishing, remove section ID from API call so that full wikitext is published properly. 3. Performance: see notes from spike on performance findings. My proposed solutions are that we ensure the loading banner displays up until wikitext is visible in the editor (inserting long text into the editor takes several seconds), as well as remove the ability to change font sizes for full page editor. 4. Analytics work will be handled in a separate task.

Follow up from full page editing spike: T328591 This task is to update our article view to allow for full page editing. We are going to lean on our current section wikitext editor flow, so design should consider how that currently works and document if any UI changes need to be made for full page editing. === Design notes === 1. Design: Add a place somewhere in our article view where a user can enter the entire the full page editor flow. 2. Design: Should any UI/copy/logic change in the existing editor when using in full-page mode? This includes any changes needed on initial modals (onboarding, edit notices, blocked messages), the standard flow screens (wikitext editor > preview > save screens), error messages when attempting to publish, and success message on article after successfully publishing. === Engineering notes === //Note: Basic prototype work is done in `full-page-editing` branch. Feel free to reference.// 1. Do some small code renaming to our SectionEditorViewController flow to allow for full page editing (like maybe rename "section" out of various places, since these code files will now support full page editing). 2. Do necessary changes to get full page editing mode working: - Make section ID optional when entering editing screens and pass in nil. - When fetching wikitext, remove section ID from API call so that full wikitext is fetched and loaded in editor. - When publishing, remove section ID from API call so that full wikitext is published properly. 3. Performance: see notes from spike on performance findings. My proposed solutions are that we ensure the loading banner displays up until wikitext is visible in the editor (inserting long text into the editor takes several seconds), as well as remove the ability to change font sizes for full page editor. 4. Analytics work will be handled in a separate task (T331937).

Follow up from full page editing spike: T328591 This task is to update our article view to allow for full page editing. We are going to lean on our current section wikitext editor flow, so design should consider how that currently works and document if any UI changes need to be made for full page editing. === Design notes === 1. Design: Add a place somewhere in our article view where a user can enter the entire the full page editor flow. 2. Design: Should any UI/copy/logic change in the existing editor when using in full-page mode? This includes any changes needed on initial modals (onboarding, edit notices, blocked messages), the standard flow screens (wikitext editor > preview > save screens), error messages when attempting to publish, and success message on article after successfully publishing. === Engineering notes === //Note: Basic prototype work is done in `full-page-editing` branch. Feel free to reference.// 1. Do some small code renaming to our SectionEditorViewController flow to allow for full page editing (like maybe rename "section" out of various places, since these code files will now support full page editing). 2. Do necessary changes to get full page editing mode working: - Make section ID optional when entering editing screens and pass in nil. - When fetching wikitext, remove section ID from API call so that full wikitext is fetched and loaded in editor. - When publishing, remove section ID from API call so that full wikitext is published properly. 3. Performance: see notes from spike on performance findings. My proposed solutions are that we ensure the loading banner displays up until wikitext is visible in the editor (inserting long text into the editor takes several seconds), as well as remove the ability to change font sizes for full page editor. 4. Analytics work will be handled in a separate task (T331937).