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

Try/all pattern exporting #747

Open
wants to merge 11 commits into
base: trunk
Choose a base branch
from
Open

Try/all pattern exporting #747

wants to merge 11 commits into from

Conversation

pbking
Copy link
Contributor

@pbking pbking commented Nov 22, 2024

Still mostly an experiment but it's working pretty well; I've been using it for (not.. in.. but for) production for a bit now.

This change adds pattern management to CBT: Both for Synced and Unsynced patterns.

With this plugin loaded Any pattern (that has Inserter: true) that is in the theme's "/patterns" folder is UN-registered. It's then made available to the Site Editor, posing as a User Created pattern (which can be edited). When the user saves the pattern the pattern file is updated (instead of the database). Any User-created unsynced patterns are saved as a file when you "Save Changes to Theme". Boom. Pattern Management.

But wait there's more.

If you create SYNCED patterns then THOSE get written to the /patterns folder too. There is an additional "Synced: true" flag saved in their file. When those patterns are loaded (and CBT is activated) then the content of those patterns are copied to the database.

There's a little snippet of code that can go along with the themes exported with these patterns that allows them to continue to be loaded as synced patterns. HOWEVER it's not necessary; if CBT is inactive and the snippet is absent the patterns will just load as unsynced patterns.

The REASON that doesn't cause problems is because none of the patterns and templates that use these synced patterns actually REFERENCE them as blocks
<!-- wp:block {ref:123} /-->
but instead by a pattern slug
<!-- wp:pattern {slug:SLUG} /-->

When CBT loads the "synced" patterns it registers an "unsynced" pattern with the content <!-- wp:block {ref:123} /-->.

This allows you to fully manage your patterns, USE them in templates (and other patterns!) and then SAVE your theme, with all of your patterns safely packed inside.

To Test

  • Start with a blank theme. Use CBT to create a blank theme.
  • Use the Editor to create an Unsynced Pattern, add content
  • Use CBT to save the theme (make sure Save Patterns is checked)
  • Observe the theme files. Note that the created pattern is included.
  • Use the editor to create a Synced Pattern, add content
  • Use CBT to save the theme
  • Observe the theme files. Note that the created pattern is included.
  • Note that the created file has a '* Synced: true'
  • Make changes to both patterns and save them.
  • Note that changes are reflected in the theme's files.
  • Make a new Synced Pattern
  • Use the first Synced Pattern in the Second Synced Pattern
  • Save the Theme
  • Note that the First Pattern is referenced in the Second Pattern by SLUG in the PATTERN block (` )
  • Delete the patterns.
  • Note that the files are deleted too.

@pbking
Copy link
Contributor Author

pbking commented Nov 22, 2024

And now, suddenly, all of the patterns in Twenty Twenty Five are... editable.

image

It's kind of lovely really.

Comment on lines +6 to +13
"mappings": {
"wp-content/themes": "./dev-env/themes"
},
"config": {
"WP_UPLOAD_MAX_FILESIZE": "128M",
"WP_MEMORY_LIMIT": "256M"
"WP_MEMORY_LIMIT": "256M",
"WP_ENVIRONMENT_TYPE": "development",
"WP_DEVELOPMENT_MODE": "all"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like this was committed accidentally.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, it wasn't an accident, though I suppose that should probably go in a separate PR.

The environment variables feel pretty necessary, when running the wp-env environment, to be running in development mode (to prevent pattern cacheing). And the mappings allows us to actually interact with the theme assets from an environment spun up from wp-env.

Both important changes I think, so I'll open up a separate PR in which to discuss the merits.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Export Unsynced (not synced) patterns to Theme
2 participants