Update creator UI based on mockup

[ryelle]

The editor should now be full screen (disable non-fullscreen mode), and have the pattern title visible.

The sidebar will have two sections (like the CPT editor), but instead of Document settings it will be Pattern meta information.

The "View" link functionality is in #29.

[StevenDufresne]

The editor should now be full screen (disable non-fullscreen mode) [...]

I'm not sure if I understand how to do this nor am I sure I'm viewing the creator properly.

I've created a page called new-pattern and I visit localhost:8888/new-pattern. I get the creator embedded in the page.

Looks like this:

When I run the snippet below, nothing happens; presumably, because i'm not loading this through wp-admin?

wp.data.dispatch( 'core/edit-post' ).toggleFeature( 'fullscreenMode' );

[ryelle]

Yep, that's what it looks like right now, and the issue is that it's been totally redesigned to use a fullscreen mode only. The current editor here doesn't have any fullscreen code.

The new version looks a lot closer to the edit-post editor, so I was thinking we might want to switch to that. I initially tried an exploration using @wordpress/edit-post, but the design was distinct enough that we couldn't use it (see #26 ). Since the design's changed, I'd like to bring try that again - it should be more stable than the forked editor we've got now.

I merged trunk into that branch & got it to build again: try/edit-post-package

If you'd like to work on the editor (I'll have a few more issues for other editor features in the next few days), could you investigate this approach? If there are any other gotchas, and/or see if there's a way around the BrowserUrl issue I mentioned in #26?

BrowserURL helper updates the page URL to site.com/pattern/pattern-name/post.php?… so you can't reload the page. There doesn't seem to be any way to disable this.

[StevenDufresne]

I'll hold off and wait for this to settle.

[ryelle]

@StevenDufresne Are you still planning on working on this? Whether it uses the branch I mentioned or can be done by just iterating on what's in trunk already, either works.

[StevenDufresne]

I have no plans. But I don't mind picking it up.

[StevenDufresne]

.... I didn't realize I was assigned to the ticket.

[shaunandrews]

Here's the latest designs for the pattern editor:

You can find all of this in Figma here: https://www.figma.com/file/bz4qs4jZCkqvQzPH2fmX6C/Pattern-Directory?node-id=1641%3A0

[StevenDufresne]

@ryelle I went through and pulled out some of the necessary changes to be done in try/edit-post-package. They seem all very doable.

Editor

• Primary color to #3858E9
• Navigation:
  • Remove preview button
  • Replace with viewport button/functionality
• Update savePost functionality
• Connect to <PublishModal> (PR: Creator: Publish submission window #112)
• Limit media to GPL

Inspector

• Update Inspector Label from "Block Pattern" to "Pattern".
• Turn off <PostStatus>
• Turn off <PostLinks>
• <PatternDetails>
  • Remove Heading
  • Add block pattern title
  • Remove Viewport from , make its own component with new designs
• Add <BlockScope> Section

Fix main Dashboard arrow/button

• Where does it go?

Document:

• Add resizing handles
• Main background color to #2F2F2F

[StevenDufresne]

I've reassigned myself and started this in a new branch with the hopes of merging it with #112 via #60.

Branch: try/edit-post-package-editor

[StevenDufresne]

I do have a couple questions before i dig in too deep:

1. In the plugins folder we have a pattern-directory and pattern-creator project. I'm not certain what the difference is seeing that we appear to have editor controls in both. For example the pattern-creator has a MainDashboardButton and the pattern-directory has controls in pattern-post-type.js. What's the idea behind those?

2. Do we plan on hijacking the Publish function within the editor?
   We did it in the revisions-extended project but we were only able to do it by replacing the button itself (the revisions extended code moved away from replacing that button so you won't see it in trunk anymore). We could alternatively replace the savePost function but there are some gotchas with that approach. If you have no opinion here, I will proceed by replacing the button.

[ryelle]

1. pattern-creator has the front-end creator UI functionality, while pattern-directory sets up the CPT. pattern-post-type.js was added when the CPT was set up, I think as a way to edit the pattern meta. You can think of it as pattern-directory for wp-admin/backend, and pattern-creator for the frontend.

   The MainDashboardButton in pattern-creator is a poorly-named file - that's the name of the slot, it should be a button to bring people back to the patterns list (or whatever "back" is). It's this ⬅️
   

2. I think we'll have to in order to show the pre-publish modal, right? I have no opinion on how to do it, I trust your judgement on this 🙂

[ryelle]

More clarification for Q1, where does the theme fit in — the theme should be for displaying the patterns & any user interaction with patterns (copy, favorite, report etc). So the patter-creator plugin is for frontend pattern creation & editing, and the theme will have all the display & moderation in it.

it's rudimentary/manual code-splitting, kind of— we don't want to load all of the editor scripts on every page, so the editor should be its own code bundle.

[StevenDufresne]

@ryelle @shaunandrews
Sorry for the big question list below. I don't know a better way of starting a discussion for these topics async :)

1. Looking at the wpop_viewport_width taxonomy, it doesn't appear to have any unit awareness (uses absint) but the new designs reference a % unit. Are we supporting all CSS unit types? Or focusing on px for launch?
2. Just for clarity, when a user updates wpop_viewport_width, it should update the block editor's document to reflect that size correct? (The one surrounded by the handles?)
3. How necessary are the resizing handles for launch? It doesn't appear to be easy to do.
4. Where does the information come from for the Block scope? Is it a new taxonomy? Is it hardcoded?
5. @ryelle The Category & Keyword controls have an added paragraph in the designs to explain their use and also remove the ability to create new terms, do you know of a way to work with the existing ones? I don't see any way other than rebuilding them.
6. Can we edit a published pattern? If not, i'm assuming we'll want to lock the editor after publish and only allow them to navigate to their patterns or create a new pattern (reload /new-pattern)... not simply close the dialog as in the pattern submission designs. Agree?

[ryelle]

1. wpop_viewport_width is a meta value, so it can be anything. It does need to be a pixel value, since it corresponds to viewportWidth in the pattern code.
2. This one's for @shaunandrews
3. I would consider it an enhancement — let's get the basics in first and see where we are. We can probably use ResizableBox, maybe with some custom styles on the handles.
4. Block scope is saved into the meta wpop_block_types, the set of block types to choose from can be the set of registered block types. We could also do some magic to make sure the selections for blockTypes are valid, by pulling out the current block types in the pattern… But for a first pass, you can hardcode a few. See Pattern CPT & API: Add block types meta field #111 (comment)
5. I don't think so, there aren't any hooks or anything in the PostTaxonomies components.
6. Yep, you can edit a published pattern. Edited patterns will go through the same flow as new patterns, with validation etc. So it's fine if the pattern is still editable after the modal closes.

[shaunandrews]

Just for clarity, when a user updates wpop_viewport_width, it should update the block editor's document to reflect that size correct? (The one surrounded by the handles?)

Correct. At some point I was thinking it might be nice to have a viewportWidth value set, but still use the handles to preview how your pattern behaves at different sizes (perhaps with a button to "return to viewportWidth").

For now, we can keep it simple, especially as it sounds like the resizableBox stuff is considered an enhancement.

[StevenDufresne]

@ryelle Are keywords supposed to be restricted to the ones created in wp-admin? Or will those be considered suggestions and users can add whichever keyword they choose? It appears like the backend is expecting a list of integers.

pattern-keywords[0] is not of type integer.

If they are restricted, would the Keyword control make sense to use as in the designs?

[ryelle]

Hm, I'd assumed that keywords would stay internal - I used it for the Core flag mostly because I didn't think it would be used for anything else... I'm not entirely sure what the difference between category and keyword is.

It appears like the backend is expecting a list of integers.

It's probably looking for a set of taxonomy term IDs, which could be created - like how the tags UI works on posts.

[StevenDufresne]

@ryelle @shaunandrews

I guess it would depend on how 'loose' we get with categories and how specific patterns become. I'm not certain we have those answers yet...

Should we remove the keyword control from the interface for now then?

[ryelle]

I apparently didn't catch that keywords is used in patterns too, just like blocks - my mistake. So this should work like tags in posts, where any arbitrary content can be entered and it will find or create the keyword-term.

You can leave this alone in #115 and make it work in a following PR.