Show demo content in dynamic blocks when creating and previewing a pattern

[tellyworth]

Should it be possible for patterns to contain placeholder blocks, such as "your image goes here"?

If so, what's needed to support that?

What kinds of placeholders are needed, besides images?

[ryelle]

I think all the media blocks have default views when an asset hasn't been picked yet:

brainstorming some ideas…

If a pattern author wanted to upload their own assets, they could upload an arbitrary image that says "placeholder"? We could provide placeholder assets, that they could upload?

We could deregister the media blocks in the creator, create our own "Placeholder Cover" (etc), and swap them out somewhere in the API process?

[tellyworth]

I like the idea of extending media blocks with our own that display a special placeholder. That way we could make them look like anything during a preview, and change it retrospectively if needed.

On the editing side, those default picker views seem just fine as a starting point. As long as we can make it save and validate sensibly (which it seems the editor is happy to do already).

We probably need to distinguish between two use cases: one where the pattern author wants to upload a fixed image/asset for reuse in the block; and the other where it's a placeholder. That's probably technically trivial but the UX might need some thought.

[ryelle]

Blocks that could use special "placeholder" handling due to file uploads:

• core/audio
• core/cover
• core/file
• core/gallery
• core/image
• core/media-text
• core/video

[ryelle]

Other placeholders might be needed for dynamic content blocks, like:

• core/archives
• core/calendar
• core/categories
• core/latest-comments
• core/latest-posts
• core/tag-cloud

These display the content on the site, but we don't want to demonstrate with the content on w.org/patterns. We should pull together some demo content that can be displayed instead.

[shaunandrews]

I don't think we need to do anything special to the media block placeholders. It's up to the designer if they want their pattern to provide an image that can be replaced, or an empty Image block; Both should work.

We will have to provide a collection of site content for dynamic blocks. Does something like this exist currently for themes that we can reuse, or will we need to create a bunch of example content ourselves?

[ryelle]

• The media blocks will use the existing media in the media library
• Query Loop, archives, etc - can use demo post content added to the site (see my comment on Horizontal Cards #179 (comment))
• Navigation menu, page list, anything else that uses pages - will need a mock API response, since we don't want to use the site's real pages.

[ryelle]

I've disabled the following blocks:

These are all used together to display site content for nav menus, and might require permissions the pattern author doesn't have to create new menus (also, those menus would not exist on the user's site).

• core/navigation-area
• core/navigation
• core/navigation-link
• core/navigation-submenu
• core/page-list

The template part block is not useful for shared block patterns.

• core/template-part

These use site info for display, which is just "Pattern Directory" etc. I'm not sure how useful these would be for shared patterns, but we can bring it back and mock the data if it's requested.

• core/site-logo
• core/site-tagline
• core/site-title

---

That leaves these blocks which use server-side rendering to display site content, I started a branch to mock the render function with some spoofed data. It's a little tedious, and could break/have unexpected results if these blocks update. They're legacy widget blocks though, so I doubt they will.

• core/archives
• core/calendar
• core/latest-comments

⚠️ The Query Loop block (and related) can be used with the existing demo posts and looks good — but it's also possible to switch the post type (to pages or block patterns). Initially I thought it would be best to mock page data, but this is actually fairly complex because the options for this use taxonomies, authors, etc. It won't be easy to mock everything. I'm not totally sure where to go for this collection.

• core/query
• core/post-template
• core/query-pagination
• core/query-pagination-next
• core/query-pagination-numbers
• core/query-pagination-previous
• core/query-title
• core/post-* - the post title, content, etc, used in the Query Loop to display content. Can also be used on their own, but it's awkward so I don't think people will (or those patterns would appear broken & naturally sort down).

[shaunandrews]

I'd expect the Navigation block and all three "site info" blocks (logo, tagline, title) to be necessary to create usable Header patterns.

Maybe the blocks can be added to a pattern, but are restricted so that you're unable to "fill them out" — that is, they always render is if they're empty. As you mentioned, it might be nicer for the title and tagline to make use of some different placeholder content, like "Site Title" and "Just another WordPress website."

--

The template part block is not useful for shared block patterns.

That's probably fine for now, but I definitely think it could be interesting to offer "full page" patterns, which could make use of other patterns like a Header in a Template Part. (My brain hurts thinking about the recursion...)

--

it's also possible to switch the post type (to pages or block patterns)

Hmmm. Maybe we remove that ability and see if people actually want/need it? I imagine the Page List and Navigation blocks would solve most use-cases, but I might be underestimating the value.

[ryelle]

That's probably fine for now, but I definitely think it could be interesting to offer "full page" patterns, which could make use of other patterns like a Header in a Template Part. (My brain hurts thinking about the recursion...)

The copying feature wouldn't really work in that case, because you'd need to create and save the template part locally too. Perhaps a v3 feature :)

Maybe we remove that ability and see if people actually want/need it?

This is the issue with just about all of these blocks - there's no way to control bits of them like that. AFAICT, I can't disable selecting a menu in the Navigation block, so anyone adding it would just run into permission errors trying to create a new menu. I can't filter out Block Patterns & Pages from the Query block without also disabling the entire pattern creator (because they both use the post types endpoint, and there are no filters).

I can open tickets for some of this customization into gutenberg, but that's not going to be ready for beta testers next week.

[shaunandrews]

I can open tickets for some of this customization into gutenberg, but that's not going to be ready for beta testers next week.

Sure. But at some point we'll need to have a way to make use of some of these blocks in patterns. Perhaps there's some clever solution using block transforms and variations that could help; Maybe the pattern directory replaces these blocks with restricted variations, and then transforms them when publishing.

[tellyworth]

Re mocking the query loop stuff: rather than mocking, can we just create some actual sample posts and pages on the site?

I can open tickets for some of this customization into gutenberg, but that's not going to be ready for beta testers next week.

Totally agree that the beta shouldn't be held up for this. It is important that we get feedback into G tickets though, I think there's some short-sightedness in the way many core blocks are designed that has implications for other use cases besides patterns (block themes especially).

[ryelle]

I think as of #489 these are all enabled.