-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Conversation
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: But we could tune the post-publish a bit, to this: 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: It totally works. |
9073c22
to
9ef0a71
Compare
Hi @jasmussen thank you for the feedback. I updated this PR, now we show a panel for "pos schedule" with the content you specified. |
9ef0a71
to
a9086a0
Compare
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. |
a9086a0
to
fd23f5b
Compare
fd23f5b
to
a1365c7
Compare
Hi @jasmussen I added a condition for that :) |
Solid! 👍👍 from me and thank you! |
There was a problem hiding this 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 ) { |
There was a problem hiding this comment.
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?
editor/store/test/selectors.js
Outdated
expect( isCurrentPostPending( state ) ).toBe( false ); | ||
} ); | ||
|
||
it( 'should return false for auto draft posts', () => { |
There was a problem hiding this comment.
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', () => { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 && |
There was a problem hiding this comment.
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 ) { |
There was a problem hiding this comment.
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".
a1365c7
to
ffc742a
Compare
Thanks @jorgefilipecosta, great work 👍 |
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 } |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
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).