Open arpadkdweb opened 3 months ago
I can confirm this. When used with a classic theme, the Group block does not have alignment options or styles.
This is what I see in block themes:
This is what I see on classic themes.
I am adding the "regression" label tentatively but perhaps classic themes never supported these settings on the group block?
I stumbled upon the same issue. It’s working for me as long as there is no theme.json
available.
Test theme:
style.css:
/*
Theme Name: TEST
Description: Test
Version: 1.0
License: GNU General Public License v2 or later
License URI: http://www.gnu.org/licenses/gpl-2.0.html
Text Domain: test
Update URI: false
This theme, like WordPress, is licensed under the GPL.
Use it to make something cool, have fun, and share what you've learned with others.
*/
functions.php:
<?php
function test_setup() {
// add Gutenberg wide and full content support
add_theme_support( 'align-wide' );
}
add_action( 'after_setup_theme', 'test_setup' );
As soon as you add a theme.json
, the alignment controls are missing for patterns, even if it just contains this:
{
"$schema": "https://schemas.wp.org/trunk/theme.json",
"version": 2
}
I can confirm this. When used with a classic theme, the Group block does not have alignment options or styles.
This is what I see in block themes:
This is what I see on classic themes.
I am adding the "regression" label tentatively but perhaps classic themes never supported these settings on the group block?
Even if I create a new block that is supposed to have support for wide and full alignment, that new block still doesn't work. So I believe this is a buggy behaviour.
Ok so, I could be wrong but this seems to be expected https://developer.wordpress.org/themes/global-settings-and-styles/settings/appearance-tools/
Classic themes will not have support for this unless they state it explicitly. I do not have the full context but I imagine this was done to prevent unintended layout consequences. In this sense, I would not consider it a bug.
I suggest closing this issue as "wont fix", but I would like to hear from you all first.
It’s at least a regression since we use this system as is quite a while and I guess it was in WordPress 6.5 when the appearance tools got removed from the toolbar in such cases. Before that, it worked fine.
And I would assume that using add_theme_support
for align-wide
should be considered to override the default of the theme.json, since it does it in the regular editor and solely does not for patterns. That would be inconsistent.
And, unfortunately, explicitly setting appearanceTools
to true
doesn’t change the behavior whatsoever. 😞
At least when it comes to the alignment setting in the block toolbar.
I believe this is a weird inconsistency and makes using the pattern editor in classic themes simply a bad experience, as the admin view will not reflect how the pattern will behave on the frontend or even when inserted in a page in the backend.
I think the expected behaviour should be the same as in the post editor. So if a block supports wide or full alignment the pattern editor should reflect that.
Thank you for checking and re-testing @MatzeKitt & @arpadkdweb. I will admit I am a bit out of my depth here. @MaggieCabrera, could you help us get some more context here?
I have the same problem,
I want to use wordpress patterns. However, I don’t have the alignwide and alignfull options on blocks (including native blocks like the gallery).
Our WordPress themes work with theme.json, so the add_theme_support( ‘align-wide’ ) function is not interpreted. And if I delete the theme.json and implement this function, the alignfull and alignwide options are available again.
Also, when testing with the Twenty Twenty-Four theme, the options are available. FSE themes don’t seem to have this problem.
In fact, the custom post type ‘wp_block’ is considered like a DESIGN_POST_TYPES. Cf comment: https://github.com/WordPress/WordPress/blob/6.5.5/wp-includes/js/dist/editor.js#L15463 To have the alignwide and alignfull alignment options, the layout must be of type ‘constrained’ or it is of type ‘default’.
Considering we are going to enable patterns on Classic themes in 6.6, it would be good to get some clarity on this one
Could you help us here, @jasmussen? Thank you!
Is this issue similar to https://github.com/WordPress/gutenberg/issues/62516? If yes, there's some discussion there that might be useful to dive into. Otherwise I would recommend a broader ping, along the lines of gutenberg-core.
Is this issue similar to https://github.com/WordPress/gutenberg/issues/62516?
I think this is the same issue described here, though the name is deceptive - it applies to any pattern created in a classic theme with theme.json.
And, unfortunately, explicitly setting appearanceTools to true doesn’t change the behavior whatsoever. 😞
The documentation on that page lists the following as affected by setting "appearanceTools": true
: border, color, dimensions, position, spacing, typography. Layout is not included. Elsewhere, the docs imply that setting the content/wide size in the layout
key should opt you into using it. However, in my testing, this bug still occurs in a classic theme with a layout
key present in theme.json.
Reiterating, it is very confusing that if you select a block with an alignment and create a synced pattern with it then the alignment is preserved and displayed on the front end, but there is no longer a way to edit it.
Description
Pattern editor in classic theme does not allow wide and full alignment options whether it's a synced or unsynced pattern. I expect the same block supports settings to be available in the pattern editor as in the post editor.
Also, it makes sense to create patterns or even complex full page pattern templates that go full width.
The pattern in my classic theme is constrained to container width.
Step-by-step reproduction instructions
Screenshots, screen recording, code snippet
Pattern editor
Post editor
Environment info
Please confirm that you have searched existing issues in the repo.
Yes
Please confirm that you have tested with all plugins deactivated except Gutenberg.
Yes