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

Improved pre/post publish flow. #5767

Merged
merged 1 commit into from
Mar 28, 2018

Conversation

jorgefilipecosta
Copy link
Member

@jorgefilipecosta jorgefilipecosta commented Mar 23, 2018

Fixes: #5343
Summary of button labels and flows as specified by @jasmussen.

Editors and admins:

Update — updates immediately, no pos-publish flow
Publish... — opens post-publish flow
Schedule... — opens post-publish flow
Contributors:

Publish... — opens post-publish flow where the confirm button says "Submit for Review".

How Has This Been Tested?

With an editor/admin:
Open a new post, write something, verify that "Publish..." button appears, press it, see the pre-post publish panel, click "Publish" and see the post-post publish panel. (basic flow)
Open a new post, write something, schedule it to the future, verify that "Schedule..." button appears, press it, see the pre-post publish panel, click "Schedule" and see post publish panel for scheduled posts. Props to @jasmussen for designing it.
Open an already Schedule post, e.g: the one before. Change it, see "Schedule" appears, press schedule and see post was updated no pre-publish panel was shown.
Open an already Schedule post, e.g: can still the one before. Change the scheduled date, for now, see the Publish button changed from "Schedule" to "Publish...", press Publish... verify pre-post publish panel appear and the normal publish flow happens.
Open a post submitted for review by a contributor, verily we see "Publish..." as publish button and the normal publish flow can be followed.

With a contributor:
Create a new post write something, see the publish button appears as "Publish...", press it, see the pre-publish panel appear, with the publish button text as "Submit for review". Press submit for review and verify the publish sidebar closes.
Open a post already submitted for review (e.g: the one before), verify the "Publish" button appears as "Submit for review" and pressing it does not show the pre-publish panel (again).

@jasmussen
Copy link
Contributor

I LOOOOVE this! Thank you so much. This is a huge improvement.

Re: scheduling

Right now it's: Schedule... → (pre-publish) Schedule → Schedule → done

For publishing, it's Publish... → (pre-publish) Publish → Publishing... → post-publish → done

I'm missing here the post-publish flow for scheduled posts. I understand why this isn't there, but it totally could be. Here's what the normal post publish looks like:

screen shot 2018-03-24 at 08 49 18

But we could tune the post-publish a bit, to this:

screen shot 2018-03-24 at 08 50 43

The flow would then be: Schedule... → (pre-publish) Schedule → Scheduling... → done

(note the term "Scheduling..." when it's working)

What do you think?


I love this:

screen shot 2018-03-24 at 08 52 21

It totally works.

@jorgefilipecosta
Copy link
Member Author

jorgefilipecosta commented Mar 26, 2018

Hi @jasmussen thank you for the feedback. I updated this PR, now we show a panel for "pos schedule" with the content you specified.
Here is a screenshot of it:
image

@jasmussen
Copy link
Contributor

Have a sick kid, so judging solely by the screenshot, and assuming that the candy-striped button says "Scheduling..." while it's working to schedule, I thin this is SOLID and good to go. 👍 👍

I think it's time to ship this! Thanks so much.

@jorgefilipecosta jorgefilipecosta requested a review from a team March 27, 2018 11:26
@jasmussen
Copy link
Contributor

Nice work! It's 99% there from my perspective:

schedule

Can you make it say "Scheduling..." when it's working?

@jorgefilipecosta
Copy link
Member Author

Can you make it say "Scheduling..." when it's working?

Hi @jasmussen I added a condition for that :)

@jasmussen
Copy link
Contributor

Solid! 👍👍 from me and thank you!

Copy link
Member

@gziolo gziolo left a comment

Choose a reason for hiding this comment

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

I left some minor comments to address before merging, but in general looks good to go 👍
This publish logic is full of conditions 😃

@@ -37,6 +37,8 @@ export function PublishButtonLabel( {
return __( 'Publishing…' );
} else if ( isPublished && isSaving ) {
return __( 'Updating…' );
} else if ( isBeingScheduled && isSaving ) {
Copy link
Member

Choose a reason for hiding this comment

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

There are very simple corresponding tests which help to avoid regressions. Can we cover this case, too?

expect( isCurrentPostPending( state ) ).toBe( false );
} );

it( 'should return false for auto draft posts', () => {
Copy link
Member

Choose a reason for hiding this comment

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

The selector explicitly checks for status so it might be enough to keep only one from those 2 tests that verify against draft and auto-draft.

expect( isCurrentPostScheduled( state ) ).toBe( false );
} );

it( 'should return false for auto draft posts', () => {
Copy link
Member

Choose a reason for hiding this comment

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

Similar as above. One of the tests might be obsolete.

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 followed your feedback and now we test for auto-draft in scheduled posts and for the normal draft's in pending posts so no tests testing the same thing exist in each test case but we still test for but status in the app.

<Button className="button" href={ post.link }>
{ viewPostLabel }
</Button>
{ ! isScheduled &&
Copy link
Member

Choose a reason for hiding this comment

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

There is no Eslint rule for that but we usually wrap an element with parentheses when after && and is multiline.

const { user, onClose } = this.props;
const userCanPublishPosts = get( user.data, [ 'post_type_capabilities', 'publish_posts' ], false );
const isContributor = user.data && ! userCanPublishPosts;
if ( isContributor ) {
Copy link
Member

Choose a reason for hiding this comment

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

Nicely moved to one place. I hope we move that logic to selector one day. Not possible at the moment without a bigger refactor :)

Summary of button labels and flows:

Editors and admins:

Update — updates immediately, no pos-publish flow
Publish... — opens post-publish flow
Schedule... — opens post-publish flow
Contributors:

Publish... — opens post-publish flow where the confirm button says "Submit for Review".
@jorgefilipecosta jorgefilipecosta merged commit 464b8c6 into master Mar 28, 2018
@jorgefilipecosta jorgefilipecosta deleted the update/pre-post-publish-flow branch March 28, 2018 11:07
@gziolo
Copy link
Member

gziolo commented Mar 28, 2018

Thanks @jorgefilipecosta, great work 👍

@gziolo gziolo mentioned this pull request Mar 29, 2018
return (
<div className="post-publish-panel__postpublish">
<PanelBody className="post-publish-panel__postpublish-header">
<a href={ post.link }>{ post.title || __( '(no title)' ) }</a>{ __( ' is now live.' ) }
<a href={ post.link }>{ post.title || __( '(no title)' ) }</a> { postPublishNonLinkHeader }
Copy link
Member

@aduth aduth Sep 12, 2018

Choose a reason for hiding this comment

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

We should not concatenate translated strings, because the order of the concatenated parts can change in localization:

Use format strings instead of string concatenation—sprintf(__('Replace %1$s with %2$s'), $a, $b); is always better than __('Replace ').$a.__(' with ').$b; .

https://codex.wordpress.org/I18n_for_WordPress_Developers#Best_Practices

Copy link
Member

Choose a reason for hiding this comment

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

To preempt: It is unsolved this need to include React elements in translated strings. We can look to some other efforts as prior art:

https://github.com/Automattic/interpolate-components

But if we don't want to solve the larger problem, we're probably better off not localizing at all here.

Copy link
Contributor

Choose a reason for hiding this comment

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

We should definitely fix this — cc @jorgefilipecosta

Copy link
Member

Choose a reason for hiding this comment

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

I might take it upon myself to look at what would be needed for component interpolation.

Copy link
Member

Choose a reason for hiding this comment

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

Description of the issue / task at #9846

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Improve pre/post-publish flow for Schedule, and Submit for Review
5 participants