Try a block-based theme with wporg-parent-2021

[ryelle]

This is a pretty quick attempt at revamping the Pattern Directory to use a block-based theme, using the wporg-parent-2021 parent theme. I spent about a day and a half on this, and got pretty far. My main goal was to see how we could work with the Query Loop for all the wporg directories, and I think it's pretty successful.

Part of this change is adding a new endpoint onto single patterns, https://url…/view/, which renders just the pattern, using the TT1 theme. This way, we can iframe a real page, and don't have to deal with loading in specific block styles — it drastically simplifies the previews.

Screenshots

The home page, with category list (custom block, built) & a placeholder for the filter dropdown (custom block, built). The pattern thumbnails, copy button, and favorite count/button are custom blocks. The pattern grid is filterable, and clicking into a category loads the category page (no more SPA).

Loading a single pattern gives a larger preview. The larger preview can be resized with the dropdown, but no draggable handles (yet? do we still need?). The content for logged in users (pattern status, management dropdown) is not built yet.

The About page looks much nicer with full block style support :)

The pattern creator still works, though it's using the theme's block.json, we'll need to filter that somehow to provide a basic one (otherwise people will try to use our custom fonts/spacing/etc).

How to test the changes in this Pull Request:

You'll need the parent theme, which i haven't officially added to the repo - instead I added a .wp-env.override.json with the following. I have the parent repo checked out next to this repo, so the relative path works. Update to match however you've set up the repos.

{
	"mappings": {
		"wp-content/themes/wporg-parent-2021": "../wporg-parent-2021/source/wp-content/themes/wporg-parent-2021"
	}
}

1. Install new dependencies yarn
2. Build everything yarn workspaces run build
3. Activate the new theme
4. Flush permalinks
5. View the site

[ryelle]

I started writing up a syncing script like build:patterns from wporg-main-2022 (having the parser code in wporg-mu-plugins would make that easier WordPress/wporg-mu-plugins#269).

Each pattern + template can be tracked in pages. The challenges:

• Some "pages" don't actually correspond to WordPress pages, like archive & category templates
• Some patterns are like template parts (archive-header, single-header, pattern-filters etc), and shouldn't have regular template files

I worked around that locally by setting up a naming convention & allowing template to be false (I didn't push this code up because it's janky and relies on a forked wporg-mu-plugins).

[
	{
		"slug": "my-patterns",
		"template": "page-my-patterns.html"
	},
	{
		"slug": "favorites",
		"template": "page-favorites.html"
	},
	{
		"slug": "template-search",
		"pattern": "search.php",
		"template": "search.html"
	},
	{
		"slug": "template-archive-header",
		"pattern": "archive-header.php",
		"template": false
	},
	{
		"slug": "template-404",
		"pattern": "404-content.php",
		"template": "404.html"
	}
]

It seemed to work great, but then I noticed my page-patterns were missing the partial patterns. When a page with a pattern is opened in the editor, the pattern block is removed & replaced with the pattern contents. So the "My Patterns" page contains the single-header & pattern-filter patterns, but when opened in the editor, it's replaced with those blocks. Future changes to the pattern-filter pattern will not cascade out to My Patterns.

What we want is something more like template parts that allow PHP. Or a custom block that works like core/patterns but doesn't have the replacement feature. Or a different translation approach that doesn't require PHP.

[ryelle]

Closing, continued work in #624