-
Notifications
You must be signed in to change notification settings - Fork 46
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
Add block pattern management #287
Comments
I haven't used this plugin before, and I'm curious about the differences with this recently launched plugin for managing patterns. Will integrating your plugin add any new features different from the other plugin? |
Block Pattern Builder was primarily built for users and hasn't been updated in a bit for newer Pattern API features. In and of itself, it wouldn't add any new features. Pattern Manager was built primarily for developers as part of their workflow. It'd be an obvious choice to integrate into Create Block Theme. |
I'll ask the folks behind the other plugin too about possible integration in case there are a few ways forward here. Ultimately, just want to see what we can do in the short term to make patterns easier and easier to create and manage. |
Now that 6.3 includes the ability for users to create both synced and standard patterns from within the Editor, it would be great to revisit this issue. Creating standard patterns in the Editor and then exporting them directly to the theme, much like templates and template parts, would be amazing. cc @mikachan 😉 |
Bringing in feedback from the FSE Hallway Hangout last week as this continues to come up as as a pain point and borderline deterrent currently. Specifically, here are the notes:
“If you were to tell this to a new user for distribution, they would say no way.” - Mike McAllister. As work is underway to consider what to tackle next, I hope this can be taken into consideration! |
Just some other thoughts, which I also shared in the above-linked Hallway Hangout: My Block Pattern Builder plugin wouldn't be ideal for what theme authors would need. It was built specifically for pattern management for end-users and saves patterns in the database. Of course, this feature is now a part of core WP. What's needed is a way to write patterns to disk---files in the theme's |
I am not sure I understand the goal, let me try to summarize
Wouldn't this be doable in a similar way as when template changes are exported from the database? |
I think we must consider the long term. I believe the plan is to make template parts synced patterns. |
@aaronrobertshaw @glendaviesnz 👋 I know you've been working a lot with patterns in Gutenberg and for WP 6.4. Are there any existing plans around exporting patterns as part of the theme export? We want to explore this as part of Create Block Theme, but it would be good to know if there are any other plans within Gutenberg before we start. Thanks! |
Also acknowledging parallels with a discussion I was having with @scruffian yesterday about the importance of importing block patterns (possibly from a directory) to enable composite themes where folks can have a block theme and ad-hoc import home page (or other) templates (as block patterns) or the like from a directory -- enabling export as well would be the flip side of enabling migrations from staging to production sites -- and then the export could enable packaging it up to upload to a directory. The other thing I was discussing was that it would likely require the block that embeds patterns may need to start referring to the pattern by slug instead of by post_id -- as slug can be consistent cross-site, but if exported/imported, post_id wouldn't be. That feels like an important shift as well. Finally, if it's useful and semi-related to this area, something we cobbled together a bit ago as fork of another plugin to track usage of reusable block patterns: https://github.com/a8cteam51/Reusable-Block-Count -- which is a very basic ~100 line plugin. |
There is an open issue here about patterns breaking theme export, but we currently have no plans to pick this up as we will be focused on partial syncing for 6.5, so feel free to pick this up. This issue here will probably be related, as this work will most likely involve adding a slug to the synced patterns, as the current |
Hey folks, curious if there has been any movement on this yet? In a quick test, it looks like we're still not exporting patterns with the export zip? With a huge focus being placed on patterns as a key component of modern WordPress, builders need to be able to export them with their theme. Otherwise, what is the current proposed workflow for builders to move patterns from a local site to a live site? I know there is a json pattern export but surely we can do better than that for builders. I have lots of curious block theme adopters writing in asking me about this and I don't have a great answer. |
As you stated, the latest is that 6.6 will include the ability to bulk export patterns (58897). In terms of the work on this issue itself, none of the folks you tagged are working directly on the create block theme plugin itself. @mikachan perhaps you can speak more to this and where this might exist in terms of priorities? Of note, for anyone following, this is also a great area to contribute back :) |
Thanks, @annezazu! If I had the technical prowess, I'd be on it in a heartbeat. It would be such a huge win for block theme builders, agencies, and freelancers! |
Thanks for the question @mikemcalister and for the ping @annezazu! Currently, the plugin does not include newly created patterns in the theme export. We do still have plans to explore this, but recently we have prioritised refactoring the plugin UI and moving all functionality from the wp-admin page to the editor. It is the next thing we plan to look into, although we're considering whether it should happen in the plugin or directly in the Editor (and eventually be included in Core). One of the things we're considering is that this Gutenberg issue includes plans for addressing exported patterns, which would sit alongside the synced patterns work in the Editor. We'd appreciate any opinions either way on this: whether the ability to export patterns should sit in Gutenberg or in Create Block Theme. To confirm, from my perspective this doesn't affect the prioritisation, although it's worth noting that we can probably work more quickly in this plugin as it's a smaller codebase.
Unfortunately, at the moment there isn't a great workflow that doesn't involve copying files outside of the Editor, e.g. in a code editor. |
To me, similar to the font library, I think it would be neat to build it out first here then see about bringing it into Core proper. It seems like a way to move faster and still get features to block themers without needing to wait for Core for something we may or may not do. |
Since this thread is popping, I'd be happy to add my ideal as one perspective- Ideally, theme patterns could be overridden, with the same ability to see and 'clear' customizations that templates and template parts have. And then the ability to save those customizations via CBT back to the theme files. Similarly, it'd be great to include theme.json support for defining pattern meta, similar to templates/parts. Imagine that themes could 'lock' patterns and templates/templates parts from being edited in certain environments, perhaps by filtering theme.json or similar). So essentially, how close can we keep the pattern experience to the template experience where core handles customizations and CBT handles exporting to disk. And I agree with the idea of iterating in CBT first before worrying about core whenever possible |
Ten thumbs up to what Brian and Anne said, especially this:
If CBT is going to be the defacto theme dev tool for the time being, let's just focus there. I fear we're losing block theme devs due to the lack of a robust and reliable workflow, so getting something iterative to them sooner would be really beneficial to adoption. |
After the Hallway Hangout yesterday, I’m itching for someone to get the GitHub connectivity (as seen in Playground) into the plugin. Pretty please! 🥺 |
Thanks all for the feedback. I agree with the reasons for iterating in this plugin first. However, I think this work needs scoping out first to investigate any foundational steps that may need to happen upstream in Gutenberg. I'm mainly thinking of the upcoming changes to synced patterns in 6.7, especially WordPress/gutenberg#59272. This work would be much quicker to iterate on if patterns could be referenced via slugs rather than ids. Here are some ideas for the next steps in the plugin, which I think can happen before and during the 6.7 cycle (i.e. now!), and we can update functionality as necessary based on changes in GB for 6.7:
|
Started some initial exploration in this PR: #675 |
I added this comment: WordPress/gutenberg#62566 (comment) to Synced Patterns iteration for WordPress 6.7 I am looking at patterns from the general user kind of view. As in how do I want to customize the content I have available for my own site.
I went ahead and made a video: https://youtu.be/Y8qi7LIgZic |
@annezazu reached out to see what I thought of integrating my Block Pattern Builder plugin into Create Block Theme. One of the pain points being that the pattern creation process was a bit too manual for non-technical users.
BPB was originally built as a proof of concept of a pattern manager that I'd envisioned core WP eventually handling. The current release is not 100% up to date with the current Patterns API features, but I've been working locally to update it.
I'm happy to start on the process of a PR if this is desirable for the plugin.
If so, I imagine one thing that would need to change is prefixes. Names/prefixes:
bpb/pattern-name
bpb_pattern
bpb_pattern_category
bpb_cap_name
Any thoughts on naming/prefixing for those things?
Potential features:
The text was updated successfully, but these errors were encountered: