-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Pattern inserter: filter by source #53033
Comments
In my theme I heavily put focus on intrinsic design. . That would mean that when using a pattern, all corresponding variables must also be loaded - spacing, colors, font-sizes, globally and for specific blocks that are used within. Additionally, fonts? I'm not sure of how much this will affect the performance, but I could imagine that we'd run into situations where people start having 10+ themes installed, only to use some of their patters. |
@hanneslsm without getting too far into the weeds, I think that speaks to a need for standardised variable naming scheme. #49279 seems relevant in terms of colors.
My concern with this approach is that you lose categorisation which seems like a pretty big trade-off. If a theme bundles hundreds of patterns, it seems likely you'd still want the ability to browse by category? There may also be scalability issues considering that plugins can add patterns too. You risk ending up with a mixture of categories and theme / plugin names which might be detrimental to the browsing experience. |
This is now possible 🎉 |
When there are multiple sources (for instance; the active theme and core) it can be desirable to view patterns from one source or the other rather than all of them jumbled together.
In the future it may also be useful to offer users access to patterns bundled with installed-but-inactive themes.
A filtering mechanism in the pattern inserter could enable both of these features. A rough mockup:
Perhaps there alternative solutions? Let's discuss.
The text was updated successfully, but these errors were encountered: