Remove coming soon settings option for v2

[lsl]

Changes proposed in this Pull Request

• Splits out the settings page changes from Add/comingsoon v2 calypso #45606
• Reworks settings page to only consider v1 values and the v2 transition

Testing instructions

Regardless of etk's/0-sandbox.php define: define( 'WPCOM_PUBLIC_COMING_SOON', true );

• http://calypso.localhost:3000/settings/general/<yourtestsite>.wo\rdpress.com?flags=coming-soon-v2

Should show existing coming soon settings, switching to public/private and saving settings should remove the option.

• http://calypso.localhost:3000/settings/general/<yourtestsite>.wo\rdpress.com?flags=coming-soon-v2=false

Should leave things functioning the same as:

• http://wordpress.com/settings/general/<yourtestsite>.wo\rdpress.com

props: @roo2 / @ramonjd (alot of code got squashed/rebased out of #45606

[matticbot]

Test live: https://calypso.live/?branch=update/remove-coming-soon

[matticbot]

Here is how your PR affects size of JS and CSS bundles shipped to the user's browser:

Sections (~198 bytes added 📈 [gzipped])

name              parsed_size           gzip_size
settings               +274 B  (+0.1%)      +38 B  (+0.0%)
settings-writing       +224 B  (+0.0%)      +36 B  (+0.0%)
signup                 +201 B  (+0.1%)      +39 B  (+0.1%)
jetpack-connect        +201 B  (+0.0%)      +46 B  (+0.0%)
accept-invite          +201 B  (+0.1%)      +39 B  (+0.0%)

Sections contain code specific for a given set of routes. Is downloaded and parsed only when a particular route is navigated to.

Async-loaded Components (~50 bytes added 📈 [gzipped])

name                                                 parsed_size           gzip_size
async-load-my-sites-site-settings-seo-settings-form       +370 B  (+0.1%)      +50 B  (+0.1%)

React components that are loaded lazily, when a certain part of UI is displayed for the first time.

Legend

What is parsed and gzip size?

Parsed Size: Uncompressed size of the JS and CSS files. This much code needs to be parsed and stored in memory.
Gzip Size: Compressed size of the JS and CSS files. This much data needs to be downloaded over network.

Generated by performance advisor bot at iscalypsofastyet.com.

[lsl]

Rebased, reverted the settings page and pushed up a bit of a commit cleanup to make changes more clear: https://github.com/Automattic/wp-calypso/pull/45896/files/4ff37845dac8bb5ea137069842ad2a98274e8ce9..44aa622177e8a3cb693ca5368cc685083405e24a.

Split the settings page out in #46034 minus all the refactor cleanup, that should be safe to merge early as it doesn't change anything unless the flag is flipped on.

There is a fair bit still in here to do with launching / site creation steps.

Should we be looking at moving that stuff serverside into headstart by chance?

[ramonjd]

There is a fair bit still in here to do with launching / site creation steps. Should we be looking at moving that stuff serverside into headstart by chance?

@roo2 has something working over at #45950 using hooks, effectively bypassing headstart 🕺

As for launching, there's also an action we could hook into when a user launches a site, in the launch_site lib

[p-jackson]

There's good stuff in this PR, but I think we should write a clearer mission statement for what it is and isn't trying to achieve. That way it's going to be easier to know when this is mergeable. Can I propose a purpose of:

1. Make it possible to create coming-soon-v2 sites using the /start flow
2. Update the general settings form so that coming-soon-v1 sites can't be put back into coming soon mode after launch (only when the feature flag is enabled, we won't ship to customers yet)
3. Hide/disable any Calypso pages or settings that don't work when a site is in coming soon v2 mode (if any)

w.r.t (3) I'm thinking that most things will actually just work for v2 sites and nothing needs to be hidden, but investigating this is in scope for this PR

w.r.t (2) this is the unclearest part of the PR for me. Have I even correctly summarised how we want the general settings form to work?

[lsl]

There's good stuff in this PR, but I think we should write a clearer mission statement for what it is and isn't trying to achieve. That way it's going to be easier to know when this is mergeable.

Most of this is just iterations on the original PR ramon drafted #45167 with a few things pulled out so far, keen to split out more mergable parts if you can spot what they are.

w.r.t (2) this is the unclearest part of the PR for me. Have I even correctly summarised how we want the general settings form to work?

Currently,

If the v2 flag is enabled the coming soon settings page option will disappear once a user switches out of coming soon and hits save. It will show for any user with the coming soon v1 site option. v2 site option is completely ignored by the settings page.

With pbxlJb-q6-p2#comment-538,

This is changing in #46119, users will be able to change back into coming soon mode regardless of version, once v2 is enabled switching back and forth will upgrade your site to v2/public mode.

[p-jackson]

Currently, If the v2 flag is enabled the coming soon settings page option will disappear once a user switches out of coming soon and hits save.

users will be able to change back into coming soon mode regardless of version, once v2 is enabled switching back and forth will upgrade your site to v2/public mode.

Cool! Thanks for the clarification. I think this is a good plan. I was initially unclear whether coming-soon-v2 would re-use the same radio controls as v1, and this makes it clear that we currently don't expect the UI to change much between v1 and v2.