|
|
Close Minimize Help | ||||||||||||||
The Meta team is responsible for maintaining and managing WordPress.org websites. Our work is mostly done on the meta trac. If you see a bug, file a ticket!
We’re currently working on these fine projects, with more in store.
Check out our handbook to learn how to get involved.
Block Patterns were introduced in WordPress core in version 5.5 (May 2020) as a way to register predefined blocks in themes and plugins. Once registered on a site, these block patterns can easily be inserted into the block editor and then configured by the content creator. Block Patterns help people to add complex block-based layouts to a site in a consistent way.
Could this feature, the ability to insert community-sourced block patterns into posts from inside the edit screen, help end users unlock the power of the block editor?
Some contributors have started exploring some early technical ideas in this GitHub repo. Check it out to see what technical considerations have been identified so far.
Feedback will help this idea to be more successful. Would this idea be helpful for end users? Are there any other things that should be considered? How could this feature be implemented in an easy to use but helpful way? Please share your thoughts and suggestions in the comments below.
I like the idea.
Limiting it to just core blocks is maybe to restrictive. Maybe there is a way to limit it to blocks from core and the Block Directory.
Or areas can be marked as placeholders for blocks of a specific type like a slider or contact form to make them more universal.
I like the idea of being aware of a general type of block.
I am generally for this, but I have to ask:
How will the contemt in the blocks be reviewed for security, license issues, advertising and spam?
Why is a new part of the directory being worked on before there is a plan for a reorganizing of the theme directory?
I am asking for a long term plan, where the block patterns would be part of the plan.
Content, not “contemt”
There would definitely need to be some kind of moderation or curation for those kinds of quality issues.
Pattern and Theme Directory work isn’t mutually exclusive. The Theme Directory is a much bigger project, and needs careful handling to work with the existing universe of themes, processes, and people.
I am (hopefully) repeating things that you have already considered but I hope that the block markup is going to be validated automatically 🙂
Great idea!
One way this could work is if the patterns directory api would only return patters that are currently supported by the editor. So for example if the site has a plugin installed that registers the ‘foo’ block the editor could ask the pattern directory for all the patterns that have the
fooblock + other registered blocks.This would help ensure that the sites only get the patterns that the site supports.
This would also help the mobile editor as well since it only supports a subset of core blocks.
This is a great idea.
I’m not sure we’d be able to cache the api.wordpress.org requests effectively if the query parameters are that unique.
We could definitely have Core filter out patterns that aren’t supported, though, before they’re displayed to the user. Some blocks are only registered in JS, so it’d have to be done in the editor, rather than the local site’s API endpoint.
+make.wordpress.org/core/
I feel the Block Pattern Directory should just follow the design work done for the Block Directory here;
http://wayback.fauppsala.se:80/wayback/20201113093852/https://make.wordpress.org/design/2019/12/19/block-directory-in-wp-admin-v1/
They can also possibly support grouping so when in the Pattern selector where the theme dropdown is the additional groupings can be added to that dropdown allowing users to switch between themes and groups (external patterns).
This would be fantastic! There are already directories available but they require addtitional plugins to pull them into the wp-instance. They could also serve as inspiration and illustration on how this could work.
I second @garrett-eclipse comment to continue work on the designs done for block entity management from last year. There is a need to have a better handle on block management than the current implementation.