Remove custom layout declarations.

[StevenDufresne]

Fixes #389

This PR removes the custom Layout object that modifies internal Gutenberg functionality to allow custom block alignments.

Gutenberg supports full width alignments when add_theme_support('align-wide') is added to a theme. We have that included in our functions.php which is why the full-width alignments show up when adding blocks on a new post/page. However, new-pattern uses our own import of the Editor/BlockEditor and therefore behaves differently. The problem here was solved in two steps:

• Remove the custom layout passed into the Block editor
• Set supportsLayout to false for the block editor.

Considerations

• If we allow users to set widths that are not supported in their themes, is that a problem? No, the alignment tool will not show anything selected when a user toggles the control and once the user updates the pattern on their site, it will replace the pattern's default.
• Is turning off supportsLayout going to cause problems in the future since it's a forward-leaning feature?
  • I don't think so, but not sure. But since it's only affecting how patterns are created, we can remove it in the future if it causes problems.

Screenshots

Enabled on Image Block

Enabled on Group Block

How to test the changes in this Pull Request:

1. Visit new-pattern
2. Add an image block
3. Verify you have all the alignments shown in screenshot.
4. Save pattern with a "full" alignment
5. Copy your pattern and expect to see that alignment attached.

Reading/Code References

• Where Gutenberg determines alignment support: Link
• The default layout configurations: Link

[ryelle]

Can you briefly explain what supportsLayout does? I don't really understand why setting that to false doesn't turn off the wide/full layouts.

[StevenDufresne]

Can you briefly explain what supportsLayout does? I don't really understand why setting that to false doesn't turn off the wide/full layouts.

Leaving it true, removes the wide/full layouts.

To be honest, I can't say that I understand the code flow 100%, but here is some evidence:

• The Editor used for posts/pages have supportsLayout set to false.
• The contentWide and wideSize variables are always undefined when it's true.
  • I think it's related to our theme not having a theme.json with the specific properties... but not 100%.
• When it's true we fall into this block.
  
  • The layoutAlignments is missing the "full" alignments because contentSize and wideSize are not set.
  • Ie ['none', 'left', 'center', 'right',].filter( ( { name: alignmentName } ) => ['none', 'left', 'center', 'right', 'wide', 'full' ].includes( alignmentName ) );

Ref: PR that introduced this logic.

I decided to stop digging deeper into the code since the page/post editors have it false and I currently don't have an elegant way to test gutenberg and a custom editor. If we are not comfortable with setting it to false, i can dig in a bit deeper.

[ryelle]

Okay, I think I get it, that it's about the layout controls not specifically about the wide/full alignments, but has the effect of enabling wide/full since we don't set layout values in a theme.json. I think leaving it false makes sense for now. We might run into issues if people want to submit site layout patterns, but we can make an issue & figure that out if/when it comes up.