Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Coming soon: Send public_coming_soon site creation flag in development builds #45428

Merged
merged 7 commits into from
Sep 15, 2020

Conversation

p-jackson
Copy link
Member

@p-jackson p-jackson commented Sep 7, 2020

Changes proposed in this Pull Request

  • Opt-in to coming soon v2 behaviour if ?public-coming-soon is present and on wpcalypso.wordpress.com or a development build
  • Send public_coming_soon flag to /sites/new endpoint
  • Disable private-by-default behaviour
  • Set new coming-soon sites as non-indexable

The public_coming_soon API option was merged in D49202-code, and it just sets the wpcom_public_coming_soon site option.

Part of #45019

Testing instructions

  • Create a new site with localhost:3000/new?flags=gutenboarding/public-coming-soon
  • The ?flags query param will disappear as you go through the flow, but that's ok
  • Open network tools and preserve log to make it easier to inspect the call to /sites/new
  • Create a site with any plan other than ecommerce
  • Check that the call to /sites/new included a public_coming_soon=true option.
  • After site creation you should be taken to the editor (notice the launch button is missing, we'll fix that in Coming Soon: "launching" a site #45016)
  • Go to the site settings in calypso and see that the site is public but with indexing disabled
  • Create a new ecommerce with with the ?flags=gutenboarding/public-coming-soon flag set, it should still be created public and indexable
  • Create new sites without the ?flags flag set, it should behave as before
  • Were you redirected to the correct place after gutenboarding? Even after going through the checkout? For ecommerce sites your site should go atomic and you should land on a store onboarding flow. For all other plans you should eventually drop into the editor.

@matticbot
Copy link
Contributor

@matticbot
Copy link
Contributor

matticbot commented Sep 7, 2020

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

App Entrypoints (~161 bytes added 📈 [gzipped])

name                 parsed_size           gzip_size
entry-gutenboarding       -648 B  (-0.0%)     +161 B  (+0.0%)

Common code that is always downloaded and parsed every time the app is loaded, no matter which route is used.

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.

@p-jackson p-jackson force-pushed the add/public-coming-soon-flag-dev-builds branch 2 times, most recently from 79853fb to 4f2ba2b Compare September 7, 2020 20:31
@p-jackson p-jackson force-pushed the add/public-coming-soon-flag-dev-builds branch 2 times, most recently from 28aaa96 to 211ec35 Compare September 9, 2020 05:16
@@ -74,6 +74,7 @@ export function* createSite(
font_headings: selectedFonts.headings,
} ),
use_patterns: isEnabled( 'gutenboarding/use-patterns' ),
public_coming_soon: isEnabled( 'gutenboarding/public-coming-soon' ) || undefined,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this will need to be updated to the new flag name wpcom_public_coming_soon.

Is the || undefined necessary? that would be the same behavior as leaving it off wouldn't it?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this will need to be updated to the new flag name wpcom_public_coming_soon.

This is an API param so doesn't actually need to map directly to the site option. But maybe leaving out the wpcom_ when the name is so similar just makes it confusing.

Is the || undefined necessary?

It might not be. I wanted to leave out the param from the payload if it's disabled, but I didn't actually test that the || undefined was necessary.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to be clear sending public_coming_soon=false would still do the correct thing, I kinda just wanted to leave it off entirely though.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I saw the existing code was doing the ...( someBool && { ... } ) trick to leave out some options. So I switched to that instead.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ahh ok I see why it's neccessary 👍

);

if ( isEcommerce ) {
return 1; // Public and discoverable
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you should use a named constant here instead of the number and comment e.g.

return PRIVACY_MODES.PUBLIC_AND_DISCOVERABLE

I see that the API defines the meaning of those numbers but it would be better to have something more formal here I think

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good call. I could define those constants in the @automattic/data-stores package and use them in the API type definition too.

@p-jackson p-jackson force-pushed the add/public-coming-soon-flag-dev-builds branch 2 times, most recently from 8c1f45a to 7a25d18 Compare September 10, 2020 10:07
@p-jackson p-jackson marked this pull request as ready for review September 10, 2020 10:55
@p-jackson p-jackson added [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. and removed [Status] In Progress labels Sep 10, 2020
@roo2 roo2 assigned roo2 and unassigned p-jackson Sep 15, 2020
@ramonjd ramonjd requested a review from a team September 15, 2020 04:25
@ramonjd ramonjd force-pushed the add/public-coming-soon-flag-dev-builds branch from 9f64d7e to 3077113 Compare September 15, 2020 05:02
@ramonjd
Copy link
Member

ramonjd commented Sep 15, 2020

I think this is good to go.

@lsl @roo2 Any objections to enabling the coming soon feature flag?

✅ Create a site with any plan other than ecommerce
✅ Check that the call to /sites/new included a public_coming_soon=true option.
Screen Shot 2020-09-15 at 2 33 26 pm
✅ After site creation you should be taken to the editor (notice the launch button is missing, we'll fix that in #45016)
✅ Go to the site settings in calypso and see that the site is public but with indexing disabled
Screen Shot 2020-09-15 at 2 34 26 pm
✅ Create a new ecommerce with with the ?flags=gutenboarding/public-coming-soon flag set, it should still be created public and indexable
Screen Shot 2020-09-15 at 2 38 43 pm
✅ Create new sites without the ?flags flag set, it should behave as before
Screen Shot 2020-09-15 at 2 48 51 pm

✅ Were you redirected to the correct place after gutenboarding? 🆗
✅ Even after going through the checkout? 🆗
✅ For ecommerce sites your site should go atomic and you should land on a store onboarding flow. 🆗
✅ For all other plans you should eventually drop into the editor.

@@ -34,7 +34,9 @@ export function* createSite(
username: string,
languageSlug: string,
bearerToken?: string,
isPublicSite = false
visibility: number = isEnabled( 'gutenboarding/public-coming-soon' )
? Site.Visibility.PublicNotIndexed
Copy link
Contributor

@lsl lsl Sep 15, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this defaulting sites to the not indexed option?

e: swapped out on launch maybe?
e2: never mind caught up now #45019

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep. This default argument is never actually used (a value is always passed it), but sites in coming soon mode start as unindexed.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

@roo2 roo2 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep I've tested this with and without the feature flag and with ecommerce plan ✅ and the code looks good 👍

Copy link
Contributor

@lsl lsl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested, LGTM

Ecommerce sites aren't currently private-by-default, and also shouldn't
use the new coming soon feature.
To silence warning that broke unit tests
The site was being created before the `useSelectedPlan` hook could
update, which meant the plan passed to the `createSite` action wasn't
up to date.
@p-jackson p-jackson force-pushed the add/public-coming-soon-flag-dev-builds branch from 3077113 to b994df8 Compare September 15, 2020 22:58
@roo2 roo2 merged commit c88eb9b into master Sep 15, 2020
@roo2 roo2 deleted the add/public-coming-soon-flag-dev-builds branch September 15, 2020 23:25
@matticbot matticbot removed the [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. label Sep 15, 2020
@lsl lsl mentioned this pull request Sep 16, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants