Pattern Creator: pattern previews are misleading due to lack of full width and layout features in the post editor

[miksansegundo]

Related to #628

Describe the bug

When creating a pattern using the Pattern Directory editor (aka pattern creator) in the directory, contributors can get confused by the editor preview because the directory uses the post editor, which lacks support for:

• Full width
  The width is limited by the theme's contentWidth (680px) on the preview. This seems expected because the directory uses the Post editor to create patterns.
• Layout toggle
  This toggle to switch between flow and constrained layout does not work on the preview.

To Reproduce

Steps to reproduce the behavior:

1. Go to https://wordpress.org/patterns/new-pattern/ to contribute to the directory creating patterns
2. Add a gallery of images and expect to see the columns borked on the preview.
3. Add a group with an image in it, use the Layout toggle, and expect to see no effect on the preview.
4. Rather than design your pattern directly in the Pattern Directory editor, go to the Site editor of one of your sites, design a full-width pattern, then copy-paste it into the Pattern Directory editor to submit a pattern to the directory, and expect to see your pattern borked because the max-width of the editor preview is 680px.

Expected behavior

Pattern previews in the Pattern Directory editor should look like pattern previews in the Pattern Directory.

Screenshots

See in the following screenshots how patterns look as expected in the Site Editor and the Pattern Details of the Pattern Directory but look borked in the Pattern Directory editor.

Pattern Directory Editor	Pattern Details	Site Editor

Pattern Directory Editor	Pattern Details	Site Editor

Please look at the following recording of how the Layout toggle doesn't work.

Pattern Directory Editor	Site Editor
Screen.Recording.2567-04-11.at.19.04.37.mov	Screen.Recording.2567-04-11.at.19.07.32.mov

Additional context

Submitting a pattern confuses contributors because of the misleading editor preview. As a workaround, we use the Site editor in our sites to design patterns and then copy-paste them into the Pattern Directory editor to submit them.

Ideally, patterns should be created from the Site editor because that is the pattern creation flow contributors have been using since WordPress 6.3 to create custom patterns. As a reference: https://learn.wordpress.org/tutorial/creating-your-own-custom-synced-or-non-synced-patterns/

I'd like to help to improve this experience. cc: @annezazu @richtabor @ryelle Any ideas?

[ryelle]

The pattern creator actually uses a custom-built editor, based on the post editor. The code is in the pattern-creator directory in this repo.

It is definitely not ideal— it worked when the directory launched, but as Gutenberg has evolved it's not kept up. We need to include a few private APIs, for things like the layout, but I don't think it's being done correctly. I would really like to remove the separate creator entirely and let people use the core post-type editor, as that would at least look correct:

"Block pattern" post type editor

(but I haven't had time amidst other priorities to fully test this out)

Ideally, patterns should be created from the Site editor because that is the pattern creation flow contributors have been using since WordPress 6.3 to create custom patterns

There are restrictions around what users can do on WordPress.org, so we probably can't make the site editor work — the block patterns are a custom post type, not related to the actual patterns on the site, for one thing. We also don't want any user to be able to change theme-related things on the site.

[richtabor]

It is definitely not ideal— it worked when the directory launched, but as Gutenberg has evolved it's not kept up.

What's the worse that can happen if we removed all the custom stuff and just had the custom pre-publish checklist and the Openverse connection? Just using the latest core theme as the default editing experience.

[annezazu]

+1 to Rich here! I'd love to see that but am not sure what major drawbacks there would be as I know the initial implementation has been thoughtfully considered.

[ryelle]

What's the worse that can happen if we removed all the custom stuff and just had the custom pre-publish checklist and the Openverse connection?

Like I said, I'd like to try getting rid of it, but the entire thing is custom. We would need to build a pre-publish checklist, make sure the openverse integration works on a non-custom editor, make sure that users only had access to the things they should, ensure moderation (automated and the UI for humans) still works, etc. In some downtime I have started looking into this, but it would probably benefit from a week of dedicated work.