Introduction

This PR is part of #9171. It introduces a Publishing Tools card under Writing Settings. This card will be used to manage the settings of the Post by Email module, and will also shelter the Press This block.

Preview

Post by Email disabled

Post by Email enabled

Post by Email enabled, regenerating

Testing

• Checkout this branch.
• Select one of your Jetpack sites that has Jetpack 4.5 or newer.
• Go to /settings/writing/$site, where $site is the slug of your Jetpack site.
• Verify the Publishing Tools card is displayed properly as shown on the previews.
• Play with the main toggle that toggles the Post by Email module, and verify it saves correctly in your Jetpack site.
• Verify that the Post by Email settings are displayed only when the Post by Email module is active.
• Try copying the email address and verify it works properly.
• Click "Regenerate Address" and verify it disables just the Post by Email form and nothing else. Verify it loads a new email shortly after.
• Verify the link of the info popover is working as expected and lead to the right place.
• Test with a Jetpack site with Jetpack 4.4.2 or older and verify the card is not shown.
• Test with a WordPress.com site and verify that the card is not shown at all,
• Test with a WordPress.com site and verify that the Press This block is shown as a separate card.

Final notes

This PR has borrowed the Redux functionality from #10811, but I'll remove it once #10811 is merged.

Test live: https://calypso.live/?branch=add/jetpack-settings-publishing-tools-card

Looks great!

i haven't worked a lot with post-by-email, so i was a little surprised that it defaults to an empty field even though the module is active. but that seems to be expected, as it also happens

Yes, I realize this might be not the most intuitive UI for the case when the module is activated but there is no email generated yet.

@MichaelArestad what can we do to improve this? I have several ideas - when you initially activate Post by Email, or it's activated but email is not generated:

• Add a notice/nudge below the module toggle that would say something like "You need to generate an email address - click here to do it".
• Change the button from "Regenerate" to "Generate".
• Hide the ClipboardButtonInput when there's no email generated yet.

We can use one or more of these, @MichaelArestad what do you think? Marking as "Needs Design Review" again.

also, generating a new email address works as expected. BUT, when i switch to an other site using the site picker, the post-by-email settings load up with the same email generated for the previous site. we need to fix that.

Good catch, thanks for that! It appears we were handling null emails incorrectly. I've fixed this in 5067999

@roccotrip this one is ready for a new code review, too.

but that seems to be expected, as it also happens

what can we do to improve this?

I'll wait for Michael's word on this, but... can't we just generate it automatically if the field is empty, showing a pulsating skeleton while the email gets generated? Maybe I'm missing some step here, but experience wise I would expect to just get the email.

@folletto the problem with automatic generation upon activating is that it wouldn't help for a most of the cases. The Post by Email module is enabled by default with Jumpstart. So for most of the people who are not actively using that module, it will probably already be active, but without an email generated.

The Post by Email module is enabled by default with Jumpstart. So for most of the people who are not actively using that module, it will probably already be active, but without an email generated.

Ok three things then...

1. Can we generate it at Jumpstart then?
2. Can we auto-generate once the person hits that page for the first time ("if the page loads with no email, we trigger the generation automatically" condition)?
3. So the most likely situation is "already active with empty field"? In that case maybe we can change the default empty text label to "click Generate to get your post-by-email address" (or something)?

Why is there a save button here? There's nothing to save. Clicking 'regenerate' creates the email, presumably it's already active and working at that point.

I also feel like we could improve the button layout between 'copy' and 'regenerate'. Or at least we can create a standard for the 'copyable field' since I think there may be other implementations of that floating around.

One other thought—we are 'hiding' rather than 'disabling' the post by email sub-settings. Since we've decided to disable the subsettings rather than hide for other settings cards, we should do the same here—display the email field in a disabled state.

Thanks for the fix, looks good to me!

Can we auto-generate once the person hits that page for the first time ("if the page loads with no email, we trigger the generation automatically" condition)?

@folletto I've chosen this solution - if there is no email, but the module is active, email not regenerating currently and it hasn't been generated yet, this will trigger a new regeneration of the email. Seems to be the painless solution for affected users, as it does not bother them at all. It appears to work fine for my tests, but I'd appreciate some more 👀 - @roccotripaldi would you like to test that too?

Why is there a save button here? There's nothing to save. Clicking 'regenerate' creates the email, presumably it's already active and working at that point.

Good point, I've removed the "Save Settings" button completely.

I also feel like we could improve the button layout between 'copy' and 'regenerate'. Or at least we can create a standard for the 'copyable field' since I think there may be other implementations of that floating around.

@rickybanister I'm using a <ClipboardButtonInput /> here, and the regenerate button is below it. There is one case in Google Adwords credit where we use a similar layout:

As you can see, the button below is primary (blue), so perhaps it makes sense to change the "Regenerate Address" button to a primary one? @MichaelArestad do you have any thoughts on this one?

One other thought—we are 'hiding' rather than 'disabling' the post by email sub-settings. Since we've decided to disable the subsettings rather than hide for other settings cards, we should do the same here—display the email field in a disabled state.

@rickybanister Thanks for the suggestion, sub-settings will now be disabled when the module is disabled, here is a preview:

All concerns so far have been addressed. This one needs another design and code review.

/cc
@MichaelArestad @rickybanister @folletto for a new 👁 on design;
@roccotripaldi for a final code review, since I changed several things.

Seems to be the painless solution for affected users, as it does not bother them at all.

👍

My only thought is whether the Email Address label should also get some kind of dimming effect to match the disabled fields and buttons. I mentioned something similar for the Related Posts 'Preview' area.

@MichaelArestad what do you think, should we dim everything that's disabled including labels and previews?

LGTM!

@rickybanister Not previews (there's only one, right), but definitely dim the labels.

@MichaelArestad @rickybanister I've updated the label to be dimmed when the toggle is disabled, here is an updated preview of the disabled state:

If you feel this is ready to go, you can mark it as "Ready to Merge", as code has already been approved.

LGTM @tyxla Nice work again!

The dimmed label looks much better. Let's make sure we do that same treatment for all other settings with any sort of preview or example.

CC @eliorivero and @zinigor