-
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
fix: Show permalink editor in editor #7494
Conversation
@@ -123,7 +123,13 @@ class PostPermalink extends Component { | |||
|
|||
export default compose( [ | |||
withSelect( ( select ) => { | |||
const { isEditedPostNew, isPermalinkEditable, getEditedPostPreviewLink, getPermalink, isCurrentPostPublished } = select( 'core/editor' ); | |||
const { | |||
isEditedPostNew, |
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 was messing about with possibly improving how the logic to display the permalink editor worked and it meant editing the selectors used… I didn't end up doing it, but I found this a bit easier to read so left it in 😄
@@ -60,7 +60,7 @@ class PostPermalink extends Component { | |||
const { isCopied, isEditingPermalink } = this.state; | |||
const ariaLabel = isCopied ? __( 'Permalink copied' ) : __( 'Copy the permalink' ); | |||
|
|||
if ( isNew || ! previewLink ) { | |||
if ( isNew ) { |
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.
Can you provide context on why the necessary condition has changed? Put differently: what changed in the breaking PR (#7130) that requires adapting this line?
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.
So I'm a bit confused as to how it worked before and why this condition is here at all. The only time we shouldn't render the permalink editor is when the post is entirely new and hasn't been sent to the server (eg isNew === true
).
Changing this check makes the Permalink editor behave as it did in 3.0.1
… though I'll admit the lack of tests on this had me confused as to exactly what that was, so I just manually tested it 😄
To be honest it's just an educated guess but I'd think https://github.com/WordPress/gutenberg/pull/7130/files#diff-36dbe9dade73983f5ea95f585450ff2cR1091 is the breaking change. Not sure why it's there… @aduth?
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.
#7130 moved the preview_link
out of the posts endpoint into the autosaves endpoint. The autosave
state had never previously tracked preview_link
, so the referenced line from the pull request is related -- though not directly. Omitting the field is not the breakage; it's the fact that we no longer track preview_link
in the objects accessed by getEditedPostPreviewLink
. This is intentional, though apparently I did not audit the existing code to update all places where we relied on it.
In fact, the selector getEditedPostPreviewLink
should either be removed or updated to getAutosaveAttribute( 'preview_link' )
(as was done for PostPreviewButton
).
That said, there's a few issues:
- We don't populate
autosave
when the post loads, so we can't rely on it existing to retrieve a preview link. Related: Saving: Autosaveable does not account for autosave existing at start of editing #7416. - The behavior in State: Trigger autosave as standard save for draft by current user #7130 was changed to be such that the preview button redirects its popup when a preview link becomes available, so there is a short time between an autosave starting and its completion that the preview link is unset. What are we to be rendering as a link here in the meantime?
- More generally, what is the behavior of the link when there are unsaved changes? It's odd we apply the preview link, but not the mechanics of autosaving in order to show the latest preview of the post.
So I'm inclined to wonder: Should we just set this to be the post.link
from whatever is the most recent saved version of the post (currentPost
)?
There may be some additional context buried in #5756 which could shed light on why we might want a preview link 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.
Using getCurrentPost()
means we can otherwise preserve the logic here. Thanks! 👍
@@ -60,7 +60,7 @@ class PostPermalink extends Component { | |||
const { isCopied, isEditingPermalink } = this.state; | |||
const ariaLabel = isCopied ? __( 'Permalink copied' ) : __( 'Copy the permalink' ); | |||
|
|||
if ( isNew || ! previewLink ) { | |||
if ( isNew ) { |
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.
#7130 moved the preview_link
out of the posts endpoint into the autosaves endpoint. The autosave
state had never previously tracked preview_link
, so the referenced line from the pull request is related -- though not directly. Omitting the field is not the breakage; it's the fact that we no longer track preview_link
in the objects accessed by getEditedPostPreviewLink
. This is intentional, though apparently I did not audit the existing code to update all places where we relied on it.
In fact, the selector getEditedPostPreviewLink
should either be removed or updated to getAutosaveAttribute( 'preview_link' )
(as was done for PostPreviewButton
).
That said, there's a few issues:
- We don't populate
autosave
when the post loads, so we can't rely on it existing to retrieve a preview link. Related: Saving: Autosaveable does not account for autosave existing at start of editing #7416. - The behavior in State: Trigger autosave as standard save for draft by current user #7130 was changed to be such that the preview button redirects its popup when a preview link becomes available, so there is a short time between an autosave starting and its completion that the preview link is unset. What are we to be rendering as a link here in the meantime?
- More generally, what is the behavior of the link when there are unsaved changes? It's odd we apply the preview link, but not the mechanics of autosaving in order to show the latest preview of the post.
So I'm inclined to wonder: Should we just set this to be the post.link
from whatever is the most recent saved version of the post (currentPost
)?
There may be some additional context buried in #5756 which could shed light on why we might want a preview link here.
const { | ||
isEditedPostNew, | ||
isPermalinkEditable, | ||
getEditedPostPreviewLink, |
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.
Noted above: getEditedPostPreviewLink
is a useless selector, should be removed here (and altogether, since this is its only remaining usage).
Thanks for all the context here @aduth; I'll have another look soon and see about using |
b7881ea
to
7f3afdc
Compare
Cool, used |
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.
Tested this locally and it smells nice 👍
* | ||
* @return {string} Preview URL. | ||
*/ | ||
export function getEditedPostPreviewLink( state ) { |
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.
Should we deprecate this? On the one hand, it's a public 'method'. On the other, it's undocumented.
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.
It's not documented, nothing else uses it, and @aduth mentioned it just missed the cutting block during another commit. I think technically maybe we should but I feel like we're in the clear.
I will add it back, deprecate it, and wear the dunce hat if it affects anyone in the next release 😉
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.
Worth noting: It doesn't work as-is anyways, hence the original issue. Probably better to not work than to throw errors though. If we wanted full compatibility, we might redirect the result to getAutosaveAttribute( 'preview_link' )
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.
But getAutosaveAttribute( 'preview_link' )
won't work on page load, right? I tested this with new page loads of existing posts and "Add New" posts and it never broke the page 🤷♂️
* 'master' of https://github.com/WordPress/gutenberg: (69 commits) fix: Show permalink editor in editor (WordPress#7494) Fix text wrapping in Firefox. (WordPress#7472) Try another approach to fixing the sibling inserter in Firefox (WordPress#7530) fix: Improve "add block" text in NUX onboarding (WordPress#7511) Implement core style of including revisions data on Post response (WordPress#7495) Testing: Add e2e test for PluginPostStatusInfo (WordPress#7284) Add end 2 end test for sidebar behaviours on mobile and desktop. (WordPress#6877) Only save metaboxes when it's not an autosave (WordPress#7502) Fix broken links in documentation (WordPress#7532) Remove post type 'viewable' compatibility shim (WordPress#7496) Fix typo. (WordPress#7528) Blocks: Remove wrapping div from paragraph block (WordPress#7477) fix: change import for InnerBlocks (WordPress#7484) Polish library just a teeeeensy bit (WordPress#7522) feat: Add snapshot update script (WordPress#7514) Display server error message when one exists (WordPress#7434) Fix issues with gallery in IE11. (WordPress#7465) Polish region focus style (WordPress#7459) Fix IE11 formatting toolbar visibility (WordPress#7413) Update plugin version to 3.1. (WordPress#7402) ...
Description
Fixed the permalink editor not appearing. Fix #7467.
How has this been tested?
Tested locally and saw the permalink editor appear as it used to in
v3.0.1
.Screenshots
Types of changes
Bug fix.
Checklist: