Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Support adding opt-in visual styles for core blocks #6947
This PR enables separating visual block styles from those required for block function and provides a way for themes to opt into those styles. The purpose is to offer default visual styles for themes that want them without interfering with existing themes that provide their own.
Contributes to #5360.
How has this been tested?
This has been tested manually on the front and back end by adding and removing theme support for
I am working on some simple unit tests.
Types of changes
This PR enables separating visual block styles from structural styles on the front end. Core blocks may include a
add_theme_support( 'wp-block-styles' );
referenced this pull request
May 24, 2018
Thanks for separating this. We should not be removing theme styles from the editor itself — we should always show them there. Themes can unhook and overwrite, but without them the editor appears broken. That means
What we end up with is:
All are used in the editor by default. Only
Yes, any of our styles should be easy to unregister in the usual fashion. Given that it's not trivial to overwrite some styles within the editor, I don't expect this to be used much — it can lead to bugs.
Some of these styles should be kept in
style (like alignments for the categories block) asd they ar emore structural rather than visual design. The cover-image block should also be considered mostly
In general, I wouldn't move anything to
theme just yet, as we have removed most of the opinionated styles already.
Hi @mtias, thanks for your feedback. I made updates in response to your review and added unit tests. The unit test setup and teardown to save and restore global script and style dependencies are pretty heavy, so I'm not sure the tests are worth that. But they are there if we want them.
Seems good (and I'm always for tests, I get that slow tests are bad but I still think they're better than no tests), just some documentation tweaks I'd like to see before this ships.
Changes made to comments and documentation are good to me.
I feel like the tests could explain things a bit better with some comments, so I've added some notes, but after those changes are made I'd say this is good to go.