Adding theme.json
implement simple theme.json for child theme
Did some research on this.
Adding a theme.json file to a "classic" theme adds some pretty bad compatibility issues, even if you don't add anything to it.
- It removes the inner container from the Group block which could cause issues for our users relying on it.
- It changes how the
alignwideandalignfullfeatures work, which again will cause issues for existing users. - It changes what core CSS is loaded in the editor. This is something we can work with, but it would take a lot of testing.
Block styles
As of right now, the main benefits of theme.json seem to revolve around individual block styles and styling them to match your theme. Since GeneratePress doesn't really have a single predefined style, I don't see a ton of benefit here for us. I think it's better to design your theme elements in the Customizer and have those styles trickle down to all of your blocks.
Template editing
The template editing feature is interesting but still very early - too early to adopt I think. This feature is possible to enable without a theme.json file by adding this to your functions:
add_action( 'after_setup_theme', function() {
add_theme_support( 'block-templates' );
} );
However, this is largely untested with GP at the moment, and it completely removes all GeneratePress features from your pages if you use a template.
More block options
The theme.json file allows you to opt-in to more block styles like padding, margin, custom line heights etc... It's important to note that these features currently write inline style attributes to your HTML, which could become an issue down the line if you've added tons of them and want to make a design change. You can opt-in to these features without a theme.json as well:
add_action( 'after_setup_theme', function() {
add_theme_support( 'editor-font-sizes', array() ); // Equivalent to typography.fontSizes.
add_theme_support( 'custom-line-height' ); // Equivalent to typography.lineHeight.
add_theme_support( 'editor-gradient-presets', array() ); // Equivalent to color.gradients.
add_theme_support( 'custom-spacing' ); // Equivalent to spacing.
add_theme_support( 'custom-units', array() ); // Equivalent to spacing.units.
add_theme_support( 'appearance-tools' ); // Requires Gutenberg 14.0 or greater for now.
} );
As of right now, my belief is that introducing a theme.json file to the theme simply doesn't make sense. It will cause issues with existing sites and the benefits just aren't there. My hope is that things continue to progress in the future and more work is put into integrating it with us "classic" themes that are determined not to introduce problems for our existing users.
I think this link is very interesting: https://wptavern.com/wordpress-themes-directory-adds-block-themes-to-filter-menu
I also think that in the long run there is no way around FSE. theme.json and FSE are directly related. Just by this new function (for the theme selection), this will probably sooner or later not only a selection option, but standard. I think that Classic Themes will eventually slide to the back and FSE themes will be displayed by default.
Another addition: The Gutenberg Team is thinking about adding a theme support hook to leave the inner container of the group block intact: https://github.com/WordPress/gutenberg/issues/41124
For the inner container issue, we could look at doing something like this in the theme: https://github.com/WordPress/wordpress-develop/blob/6.0/src/wp-includes/block-supports/layout.php#L246
I'm researching using GP/GB Pro for a new project, and wanted to add to this discussion:
Fluid typography can be configured easily enough via custom CSS, sure; but the recommended best practice, as of WP v. 6.1, is for theme authors to do this via theme.json. (Source: CSS-Tricks).
Curious for your thoughts @tomusborne. Thanks.
@tomusborne is this related? https://learn.wordpress.org/tutorial/using-theme-json-with-classic-themes/