Gutenlypso: Disable the Publish button if the email is unverified

[mmtr]

Changes proposed in this Pull Request

Fixes #29539.

This PR modifies the PostPublishButtonOrToggle component from the edit-post in order to disable the Publish button if the email of the user is not verified.

Since it is now very different from the original component in the @wordpress/edit-post package, I decided to move it /gutenberg/editor/components so it's clear we're using a customized version.

Apart from displaying the Publish button, this component now do 3 more things if the email is unverified:

• Dispatches a lockPostSaving action, so the Publish button is disabled. Note that if the Pre-publish checks are enabled, only the Publish button from the Pre-publish sidebar will be disabled.
• Displays a warning notice with the same messages we display on the classic editor (handled by EditorGroundControl).
• Renders the VerifyEmailDialog component when the "Learn more" link is clicked.

Testing instructions

• Go to http://calypso.localhost:3000/start and create a new user without verifying the email. Don't use an @automattic.com email since they need to be always verified before logging in. You can use a personal Gmail account, even if it's already registered, by appending a + suffix (i.e. if your email is example@gmail.com, you can use example+20181219test@gmail.com). WordPress.com will considere it a different email but example@gmail.com will still receive any email sent to example+20181219test@gmail.com).
• Start creating a new post (it should use Gutenlypso by default).
• Make sure that a warning notice appears with the message "To publish, check your email and confirm your address. Learn more"

• Click on Learn more and check that the below dialog appears.

• Confirm that the "Publish..." button is not disabled and that after clicking on it, the "Publish" button on the pre-publish sidebar is disabled and you cannot click on it.

• Change the publish date to some date in the future and make sure that the verification email notice changes to "To schedule, check your email and confirm your address."
  

• On the More menu, click on Options and uncheck the "Enable Pre-publish Checks" option.

• Note that the "Schedule..." button in the header changes to "Schedule" and it is now disabled and you cannot click on it.

• Verify now the email, reload the editor and check that no notice is displayed and that the Publish/Schedule buttons are enabled.

[matticbot]

Test live: https://calypso.live/?branch=fix/gutenlypso-disable-publish-unverified-email

[Copons]

I've left a lot of comments, but I think this is definitely on the right track @mmtr! ✨

---

There is one other thing that is bugging me A LOT, and it's unrelated to this change, but this change made me realize it.

Basically, as of WordPress/gutenberg#11543 (cc @nosolosw), PostPublishButton doesn't have a disabled attribute anymore, but uses aria-disabled instead.
This seems to fix the focus loss issue they're having, but also... I can click on the button when aria-disabled and save the post (recently, I've happened to do this countless times with the disabled Update button).

In this particular case, you can try clicking on Publish, which simply opens the sidebar (it shouldn't do that, should it?).
Then click on it again and, even if the publish will silently fail (for any number of reasons, unverified email, empty content, etc), you can observe in the sidebar the Publish time changing from "immediately" to the actual current datetime.

I think that we should at the very least tackle this via CSS.
E.g.

.components-button.is-primary[aria-disabled="true"] {
  pointer-events: none;
}

[mmtr]

Thanks for the review @Copons! I just finished to push all the commits addressing your comments.

Basically, as of WordPress/gutenberg#11543 (cc @nosolosw), PostPublishButton doesn't have a disabled attribute anymore, but uses aria-disabled instead.

Good catch! In fact, this bug is present in Core, so I filed a bug there: WordPress/gutenberg#13014

In the meantime and since this is unrelated to this PR, I'd say we can fix it in Calypso with a follow-up PR applying your suggestion of using pointer-events: none;.

In this particular case, you can try clicking on Publish, which simply opens the sidebar (it shouldn't do that, should it?).

Only if the content is empty. If the email is not verified, only the button in the sidebar will be disabled. This is because PostPublishButton uses the isPostSavingLocked selector (toggled by dispatching the lockPostSaving/unlockPostSaving actions) for disabling the "Publish" button only if the Pre-publish checks are deactivated (in other words, if PostPublishButton is rendered with isToggle equals to false).

[Copons]

Testing the PR I've got into a funny case that somehow "breaks" these checks.

• Register new user.
• Keep the email unverified.
• Create a new post.
• Publish it: there are no unverified email warnings, as the site is "unlaunched".

This is correct: we allow unverified users to publish, as long as their site is not yet public.

Though, to launch a site, the user first needs to verify their email.

So, I wonder: when can it happen that a user has both a verified email and an unlaunched site—or viceversa?
Those two cases would be the only two that would enable the whole userNeedsVerification flow, with the warning and the dialog, etc. (in both Gutenberg and Classic)

cc @scruffian for adding isUnlaunchedSite to the equivalent of this in EditorGroundControl in #27962.

[scruffian]

It's possible for a user to have an unlaunched site and a verified email address. Since the process to launch a site would be to first verify the email address and then launch the site, any users who are part way through that process will be in that state.

The reverse state should be impossible - we should never allow users with unverified email addresses to launch a site.

Does that answer your question?

[Copons]

Absolutely yes, thank you very much @scruffian!
I didn't proceed with the test because I'm that lazy to keep the user email unverified, and somehow just assumed verifying the email would also automatically launch (which would definitely be odd).

[Copons]

(Sorry for the delay from my previous answer, I just now got to test it)

So, what happens then is that:

• Verified user can have launched and unlaunched sites.
• Unverified user can only have unlaunched sites.

In other words, this would never be true:

const userNeedsVerification =
	! isCurrentUserEmailVerified( state ) &&
	! isUnlaunchedSite( state, siteId );

In other words, we don't need the unverified email notice and the logic that prevents publishing a post, for both Guten and Classic.

Am I wrong on this?
Like, it's almost EOD and I've got the flu, I might very well have missed something. 😄

[mmtr]

Unverified user can only have unlaunched sites.

I think this is not true. According to #27962, only private sites are unlaunched, so an unverified user can have a launched site if it is public.

[kwight]

I noticed that while a new post loads with the verification notice and disabled Publish button, as soon as I enter content, the button is enabled again:

The second Publish button will still be disabled, but like @Copons noticed, it's functional.

Feel free to ignore this, or we can consider for a follow up: I don't think this is the right place to handle this. It would be better as part of /me/account, which should really have all of this regardless. If that screen handled this dialog content and actions (it could even be inline, rather than needing a dialog), any part of Calypso blocked by unverified emails could just link to /me/account (which our "Learn more" link would do with this approach). Of course, this ends up needing design input and so forth, so kicking down the road may be the better choice today.

[mmtr]

@kwight as I mention on #29594 (comment), it's expected to have the first "Publish..." button enabled if the "Pre-publish checks" are activated.

You can check if they are enabled by opening the "More" menu and clicking on "Options":

So, to recap:

• If the "Pre-publish checks" are activated, Gutenberg doesn't disable the first "Publish..." button because it is not considered a button but a toggle. The toggle will open a sidebar with the actual "Publish" button which is the one Gutenberg disables when the lockPostSaving is dispatched.
• If the "Pre-publish checks" are deactivated, Gutenberg disables the first and only "Publish" button in the header because there isn't any toggle than open any sidebar. That button is the actual button that will publish the post affected by the lockPostSaving action.

[mmtr]

I changed my mind and I think we should address here the issue that is allowing to click on the disabled Publish button, since it's very related to this PR so I added the needed CSS in 492ab33.

Once the issue is solved in Core, we can revert it.

[Copons]

I feel I'm overthinking on this, but I trust @mmtr in following the logic better than me. 🙂

Go for it! 🚢