WordPress
Query Loop / Post Title + Content blocks: Explore adding an Edit Post button to the toolbar
What problem does this address?
While navigating around the site editor and using patterns containing the Query Loop block, users will see a preview of the posts in their site. However, clicking on a preview of the posts via clicking on the Post Title block (or other blocks like Content) doesn't provide a way to go in and edit the post itself.
What is your proposed solution?
Could we add an "Edit Post" (or page, or whichever entity is being previewed) button to the Post Title block and similar blocks, when they're being previewed in the editor canvas from within a query loop / post template?
I'd love to hear what others think, but I'm wondering if this could be one way to help folks navigate between the site editor and content editing. For now, I imagine an Edit Post button would link through to the post editor for that particular item. However in the future, if we allowed post editing from within the site editor, it could potentially switch the entity we're currently editing.
Another idea would be to try a similar technique with nav links in the Navigation block to make it easier to go from editing a menu to editing a particular page?
Here is a quick mockup of what I mean. Would something like that be useful? We might also add a link in the block settings menu.
If you're reading this, what do you think? 🙂
@WordPress/gutenberg-design does this seem like something useful? The main idea here is to see if there's a way to make it easier for folks to switch over to edit particular content from the site editor. E.g. click on a title of a post within a Query Loop and then "Edit Post" to go in and edit that post. Or click an item in the Nav menu and then "Edit page" to go in and edit that page.
Could be useful, yes, the main headache there is, what is the post? In the screenshot, you've selected the post title. How about post content, post excerpt? It may be a source of confusion that all of those individual blocks would have "edit post" affordances.
On my mind lately is to expand the use of the contentOnly feature, which flattens all child blocks of a container. That makes it trivial to select the right block, because there's only one block to select. Is there a situation where "Post" can become such a contentOnly block, and title/excerpt/otherwise require editing that "pattern"? The main problem here is that would add yet another container in this case.
So it's not fully clear to me there's an easy win to be had here. I suspect there may be surrounding complexity we need to pick away at. Would love to hear from others.
The flow would be roughly the same as Edit Page ↔ Edit Page Header, which seems to work quite well. I reckon it's worth a try.
what is the post?
I think I'd expect any block that references post data to surface the 'Edit post' link.
The main idea here is to see if there's a way to make it easier for folks to switch over to edit particular content from the site editor. E.g. click on a title of a post within a Query Loop and then "Edit Post" to go in and edit that post.
It's an interesting exploration, but I'm not confident it will feel intuitive.
I think if we try an improved selection mechanism first—perhaps even particular to the Query Loop—where you first select the query, then select each "Post". At that "Post" level selection (which is today rendered as a singular entity in the Post Template block), we could have an "Edit post" control. That feels more like it would meet expectations.
Of course, when selecting a "Post", you can then select any block in that post (title, date, etc), and its changes are reflected across the others like it is today.
Good discussion, folks!
So, if we know that this behaviour shouldn't be limited to the Title block and should also include selecting a Row block (or any child of the Post Template block), perhaps we could achieve it via something like:
- If any block is the direct child (or perhaps further nested child) of the Post Template block + the query/post template is previewing a real list of posts, expose an "Edit post" button in the block toolbar.
I think that can give us a technical direction for trying out a prototype for this. What does everyone think?
If the logic is abstracted so that it isn't tied to any one particular block, we should be able to fine tune a PR to determine where it makes most sense to expose the button (i.e. any child block, or an allow list of any block that uses post data).
I think if we try an improved selection mechanism first—perhaps even particular to the Query Loop—where you first select the query, then select each "Post".
I do like the idea of somehow making each post in the loop selectable or improving how it's represented in the editor. It feels less clear to me what the next task would be to go in that direction, though. So personally I'd probably lean toward trying out an Edit Post button of some kind before working on the selection as it seems a bit more straightforward to implement 🤔
From a user perspective, I can share that I've helped several users who ended up accidentally deleting the "dynamic" blocks within the Query Loop Post Template and then manually adding static content with Paragraph blocks (which has a fun outcome haha).
And there is definitely confusion around how to "edit" the Query Loop "content". So I think anything that makes that more obvious and easier is a great idea.
I do want to note that I recently encountered a situation where leaving the Site Editor when working on an iPad or Phone browser resulted in losing all changes — there was no prompt to "save". So we might want to make sure that's resolved before providing an "Edit Post" option that will make it even easier to leave the Site Editor without having "saved". (I haven't done thorough testing on this and I'm not sure if it's reported already.)
I'm wondering if some kind of a "Quick Edit" modal feature might be possible from the Site Editor? Like you click something to "Edit Post" but instead of being taken somewhere else, a decent size (but not full screen) window pops up with just the basic post content, to be able to make quick changes. That could be a visual signal for a user that "hey, this content lives somewhere else, but you can do a few simple things right here". It could maybe even include an option to "Open full Post Editor". Just another idea to throw into the pot :-)
Thanks for sharing @tanjoymor!
So we might want to make sure that's resolved before providing an "Edit Post" option that will make it even easier to leave the Site Editor without having "saved"
Yes, if folks are navigating away from the site editor and there are things to be saved, we should have a prompt before navigating away đź‘Ť
I'm wondering if some kind of a "Quick Edit" modal feature might be possible from the Site Editor?
I think longer term it'd be great if folks could edit their posts from within the site editor, similar to how pages can currently be edited. Another flow that the idea in this issue might unlock is if we added a similar "Edit Page" button to navigation items in the nav menu — since we can already edit pages in the site editor, that might actually be a worthwhile idea to try out separately 🤔
I think longer term it'd be great if folks could edit their posts from within the site editor, similar to how pages can currently be edited.
Eventually, I agree. Though, tbh, I don’t love that Pages can currently be edited in the Site Editor. It’s not a complete experience (some settings have to be done from the Page Editor) but it’s not different enough for it to be visually obvious that it’s different. I’ve also run into more than one user who was thoroughly confused by their Pages being in two locations.
I love the long term vision of all content being 100% managed through the Site Editor, but I do wish we hadn’t done this partial, incremental release of that ability.
Another flow that the idea in this issue might unlock is if we added a similar "Edit Page" button to navigation items in the nav menu
Big +1 to this. I recently ran into this exact issue of a user not knowing how to get to their Pages after landing initially in the Site Editor and they tried to get to them from the Navigation block.