-
Notifications
You must be signed in to change notification settings - Fork 54
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
base: trunk
Are you sure you want to change the base?
Conversation
"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" |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
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