Navigation: nav created drafts should not render on frontend#29692
Conversation
|
Size Change: +163 B (0%) Total Size: 1.42 MB
ℹ️ View Unchanged
|
annezazu
left a comment
There was a problem hiding this comment.
I tested this by installing the Gutenberg plugin built with this PR and testing adding a link, creating a draft page, and viewing the front end. I can confirm this works as expected and resolves the original reported problem. Someone else will need to chime in to review the code and do more testing.
|
Edit: Looks like I'll need this |
|
Since we can load in menus created from the navigation editor, I'll also want to make sure that I'll tackle that tomorrow. Changes here are okay to test on the post-editor side of things. |
c93da7f to
af813c4
Compare
|
I'm holding off on any navigation editor changes until we clarify intended behavior in #29793 If we'd like changes in behavior, I think it makes sense to split that out to a follow up PR, since it might be a bigger of a change. |
b429519 to
bc4936c
Compare
|
This one is ready for review ✅ E2E breakages are unrelated and should be fixed by #29836 |
bc4936c to
e68b951
Compare
|
@Addison-Stavlo noticed differing site-editor behavior in #29396. It looks like there's another I'll try to fix that in a different PR, by having all editor implementations use a single implementation. |
e68b951 to
c015700
Compare
|
Rebased to pick up refactor + fixes in #29993 ✅ This one is ready for review. |
|
Thanks for the review @mkaz! |



Fixes #29691
Problem
Some drafts will render on the published page/post frontend. This happens in two ways:
create-a-draft.mp4
link.mp4
Why Does This Happen?
In trunk when we link from the general "link" variation this is missing the "type" attribute. Without this information, we can't blindly check to see if an id is a draft. It might actually be a term-id, leading to a bug like: #28712
Proposed changes:
Changes in this PR add the
typeblock attributes to the link consistently regardless of what link variation we use to create the link. This will fix newly added links but not existing links. (The worst case is that we have an old link to a draft that still renders on the front end).In order to support future custom post types and taxonomies, we should also return the
kind(taxonomy|post-type) to make this more clear. Type is not enough information to differentiate if we can check for draft status besides our built-in types (post,page,post_tag,category).Example custom PortfolioTag Search Result:

Before:
After:
Testing Instructions w/ WP 5.7
kindandtypeattributes are present and make sense.If it's a draft, verify that the link is visible only in the editor, but not on the published page of the navigation links.
Verify that links like
www.wordpress.orgdo not contain theidtypeorkindblock attributes.Testing Instructions w/ WP latest (Custom Link Variations)
item_linkanditem_link_descriptionkindandtypeattributes are present and make sense.kindandtypeattributes are present and make sense.www.wordpress.orgdo not contain theid,typeorkindblock attributes.Test Post-Format Links
A post format link looks like
http://wordpress.local/type/quote/. This points at the archive of a post type format like quote or image.To test:
Install a theme that supports post-formats like Twenty Thirteen
Create a post using one of the post-format types like "Quote"
Add a navigation block
Add a navigation link using the general link variation
Search for the post-format and individual quote
Verify that the individual link to a quote has type 'post' and kind 'post-type'.
Verify that the link to the post-format only has
urlandlabelBehavior when loading links from a menu
TODO:
packages/editor/src/components/provider/use-block-editor-settings.jstopackages/edit-navigation/src/index.js.