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

Synced patterns: indicate trashed and draft status in the editor #52013

Open
carolinan opened this issue Jun 28, 2023 · 14 comments
Open

Synced patterns: indicate trashed and draft status in the editor #52013

carolinan opened this issue Jun 28, 2023 · 14 comments
Labels
[Feature] Patterns A collection of blocks that can be synced (previously reusable blocks) or unsynced Needs Design Feedback Needs general design feedback. Needs Design Needs design efforts. [Type] Enhancement A suggestion for improvement.

Comments

@carolinan
Copy link
Contributor

What problem does this address?

Synced patterns that have been published and placed in content, but then set to draft or trashed, display in the editor but not on the front.
It is not possible to see the pattern's status in the editor.

The only visual difference between a published pattern and the draft/trashed is that the pattern-specific name is not used in the list view:
Draft, trashed and deleted pattern in the block editor.

@carolinan carolinan added [Feature] Patterns A collection of blocks that can be synced (previously reusable blocks) or unsynced [Type] Enhancement A suggestion for improvement. labels Jun 28, 2023
@aristath aristath added Needs Design Feedback Needs general design feedback. Needs Design Needs design efforts. labels Jun 28, 2023
@annezazu
Copy link
Contributor

@WordPress/gutenberg-design for more thoughts. This feels like something to iterate on for 6.3 as well but curious what others think.

@jameskoster
Copy link
Contributor

I suppose this behavior is consistent with the old reusable block experience, so not really a "new" problem? That makes me wonder how urgent it is to fix. Template parts behave the same way as well.

That's not to say we shouldn't polish if there are good ideas. A couple of questions to ponder:

  • Should it be possible to set patterns as draft in the first place?
  • When deleting a pattern, should there be an option to keep instances but detach them from source? Figma does something like this and it's quite handy, though I acknowledge it may be a technical nightmare :)
  • If we hide the blocks on the canvas (seems reasonable to preserve the preview in site view, and match the frontend) then what happens when you select the block in list view?

@jasmussen
Copy link
Contributor

Perhaps the closest existing pattern we have is that you can draft a page from the navigation menu, and then it shows up like this:

Screenshot 2023-06-29 at 09 48 07

As a small fix, should we just set the title of the pattern to "Name of pattern (Draft)"? (Or even "(Trashed)")

That said, there needs to be in combination with this an intuitive central management place to change the status of these to untrash or publish them. The Design > Patterns section feels like an obvious place to link to, since it wouldn't take you out of the singular site editor flow, so manageing trash and status there seems related.

@carolinan
Copy link
Contributor Author

I think @jameskoster brings up an important point about the draft mode, and that is probably a decision that needs to be made as soon as possible, it might be more difficult to change, the longer we wait?
I am not sure how removing the draft option would impact existing reusable blocks.

Other than that I don't think UI changes for showing the state needs to be prioritised for 6.3.

@jasmussen
Copy link
Contributor

For me it seems mostly a technical question, can the draft status even be removed? If yes, I'd agree that there doesn't seem to be a compelling use case for draft RBs.

@jasmussen
Copy link
Contributor

The most basic fix could likely be to treat draft and private statuses same as "deleted". Right now if a post includes a deleted reusable block, you get this message:

Screenshot 2023-06-30 at 09 40 10

@liviopv
Copy link

liviopv commented Jun 19, 2024

Just landed on this issue while researching existing issues about the "Draft" status for Patterns. I talked to a user who got used to accessing the deprecated WP Admin screen for patterns (they bookmarked the URL) and they made use of status in Patterns heavily to distinguish between patterns they were using on the site and patterns that were no longer in use but they still wanted to keep on the site in case they ever need it again.

While not the most common use case, I see some benefit in having a way to hide patterns from the inserter by switching their status, but keeping them archived on the site for safekeeping.

Another possible use case is builders/agencies wanting to hide patterns from clients while they are not ready to be used.

@jameskoster
Copy link
Contributor

As patterns mature, it does seem reasonable that a designer might want to work on a pattern without necessarily making it available for insertion. Utilising the existing draft / published statuses seems fairly natural in terms of UX, with draft patterns not appearing in the inserter.

It gets a bit trickier with synced patterns though. What happens to instances of a synced pattern if the status changes to draft? One option could be to leave it visible on the canvas when editing the page (with some hint relating to status), but hide it on the frontend.

Screenshot 2024-06-20 at 14 15 18

@jasmussen
Copy link
Contributor

What happens to instances of a synced pattern if the status changes to draft?

To be responsible with existing sites, a good question to ask first is, what happens if you do this today? If the pattern remains even if the source turns to draft, backwards compatibility might simply spell out some rules for us. But if the pattern becomes invisible also on the frontend, when the status changes, then that suggests your idea could work.

@jameskoster
Copy link
Contributor

I may be wrong, but I don't think there's a UI for making patterns into drafts, so I'm not sure how to test this.

Slightly different, but if you delete a synced pattern then edit a document containing an instance, the canvas shows an error and the pattern isn't visible on the frontend.

Screenshot 2024-06-21 at 14 22 45

I feel the suggestion above is a reasonable middle-ground. Draft patterns are:

  • Not exposed in the inserter
  • Visible on the canvas/List view if previously inserted (with "Draft" marker)
  • Not visible on the frontend

@carolinan
Copy link
Contributor Author

carolinan commented Jun 28, 2024

It is the "classic" pattern screen that has the draft and move to trash options.
wp-admin/edit.php?post_type=wp_block
This page can still be accessed even in 6.6, regardless of the type of theme that is active.
There are also the patterns that were created before 6.6, using a classic theme.

Edit: If you are testing this with a pattern created on 6.6, you can for example trash and then restore a pattern.

@jameskoster
Copy link
Contributor

Thanks.

I still see two parts to this, probably to be handled separately:

  1. Improve the handling of existing draft patterns in the editor (how do you feel about my suggestion above?)
  2. Decide whether we want to continue supporting a draft state for patterns, and if so create a UI for that (likely reusing the status UI from posts/pages)

@carolinan
Copy link
Contributor Author

I don't mind the draft status showing in the toolbar, but I can understand if there are objections to it being that prominent.

@jameskoster
Copy link
Contributor

Okay so the action items would be;

  • Ensure draft patterns do not show up in the Inserter
  • Add the 'Status' UI from the post/page Inspector to the Pattern inspector
  • Add a marker to the toolbar for draft synced patterns

Want to update the OP with the designs?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Patterns A collection of blocks that can be synced (previously reusable blocks) or unsynced Needs Design Feedback Needs general design feedback. Needs Design Needs design efforts. [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

No branches or pull requests

6 participants