Gutenberg: Reusable Blocks: Not receiving alignment attribute in editor

[brettsmason]

Describe the bug
I'm attempting to use the shared blocks feature but have hit an editor specific issue with alignfull and alignwide. When converting a a wide or full width block to shared, in the editor view the block looses its width. This does not apply to the front end which works fine.

To Reproduce

1. Create a block that supports full width/wide width (eg cover block).
2. Save the block as a shared block.
3. The block is no longer the width specified.

Expected behavior
I expected the shared block to keep the current data-align: full/wide that non-shared blocks receive when setting the alignment. This makes it very difficult currently to use shared blocks for aligned blocks, as its not an accurate representation of how the block actually looks.

Screenshots

[brandonpayton]

I am able to reproduce this.

[notnownikki]

Looks like getBlock in packages/editor/src/store/selectors.js doesn't apply the filters needed to add the extra props and attributes for features provided by the supports hooks. I'll see what I can figure out.

[notnownikki]

@youknowriad @noisysocks could I get a bit of feedback here? The reusable block is got with the originalContent but the features supplied by the supports hooks are only applied on save, so we'd have to use getSaveContent from the blocks serializer to make sure the reusable block has exactly the same output as the original block would have when it's ~saved~ shown in the editor. Does that sound like an acceptable solution?

[notnownikki]

oook, so that's not quite the problem. I'm still investigating, but it looks like when the block is rendered, the align isn't applied because it's taking the supports from the block block, instead of the cover block.

[notnownikki]

Yeah, that seems to be the problem.

When the filters are applied, they get core/block and because core/block constructs a BlockEdit element insides its render, it never gets exposed to the filters it needs for supports to work.

Not sure how to handle this one yet.

[jasmussen]

I can explain why this is happening. I don't know that we can get this fixed for 5.0, but perhaps we can for 5.0.1. But it's important to note — _this is an issue isolated to the editor, the front-end view will still render correctly_.

All blocks in the editor have a max-width, and are centered.

Blocks with align-wide have a _wider_ max-width, and blocks with align-full have _no_ max-width and therefore span the full width.

If you convert a wide image into a reusable block, it is now a wide image _wrapped_ in a reusable block container. I.e. the image inside the container still has a wide alignment, but it is now constrained by the parent block, the reusable block container, which has the same max-width as any other normal block.

I can think of two ways to fix it:

1. Make all reusable blocks always be fullwide. Any blocks stored inside will retain their max-widths and be correctly centered. See:

1. Let the reusable block detect that a child block inside has a wide or fullwide block, and assign that attribute to the reusable block group itself. That way the reusable block will be wide when a child is wide, and fullwide when a child is wide.

2 is arguably the best user experience, but is probably also the most complex.

1 is _relatively_ trivial to implement, but is arguably a little confusing. But it still might be the best way to do it. Assigning for some design feedback.

[notnownikki]

It's not specific to align either, any feature applied with the supports block attribute does not get applied to reusable blocks in the editor. So there's the design aspect, and having supports propagate to reusable blocks too.

[jasmussen]

If we had access to the CSS :has this would be easy to fix. But I wonder if that selector will ever come to pass or be performant.

[noisysocks]

Note that a reusable block can consist of several blocks, which complicates things. What should the supports.align value be for a reusable block that has a Cover block and a Paragraph block?

oook, so that's not quite the problem. I'm still investigating, but it looks like when the block is rendered, the align isn't applied because it's taking the supports from the block block, instead of the cover block.

That's right, the editor will use the supports, description, title etc. that's defined by core/block.

We could have editor/src/hooks/align.js have a special case for core/block which looks up the referenced block type and use its supports attribute. I think that it's fine to treat core/block as a special case since it _is_ a special block in that it implements some of the editor's core functionality.

[jasmussen]

Note that a reusable block can consist of several blocks, which complicates things. What should the supports.align value be for a reusable block that has a Cover block and a Paragraph block?

It is not unlikely that I'm missing something, so forgive me if I am.

But what I'm suggesting in https://github.com/WordPress/gutenberg/issues/8288#issuecomment-439486071, to clarify, is that _no matter the blocks inside a reusable group supports, if we make the reusable block group full width, the children will render correctly. Simply because when the reusable block group is fullwide, then there is room for the children to be constrained by their intrinsic max-widths.

Is that not right?

In other words, a "fix" could be either:

1. Always making reusable block groups fullwide
2. Making resuable block groups have the widest alignment of any of the children

To elaborate on 2, if you have 10 blocks in a reusable group, and one of them has align-wide, it's enough that the reusable block group receives align-wide. If one of them has full-wide, it's enough that the reusable block group receives full-wide.

[noisysocks]

I moreso just wanted to drop a note to remind ourselves (myself?) that 1 reusable block ≠ 1 block 🙂

You're totally right, and either of the two fixes you described would fix the issue.

1. Always making reusable block groups fullwide

This is easy to do, but it wouldn't be the best UX as you say 🙂

1. Making resuable block groups have the widest alignment of any of the children

I'd much prefer this if we can get it to work. The challenge is that alignment is calculated by looking at the block's supports attribute which is completely static. We could investigate making it more dynamic or adding a special case for core/block.

[jasmussen]

Thank you for the sanity check and clarification. I agree the 2nd option is the nicer one. But the 1st option would be one we could implement _right now_, if this needed an urgent fix. However given that it's "only" an visual inconsistency in the editor, and the front-end works as it should, I wouldn't call it critical enough to rush a fix for.

[codetipi]

Can I add that this also happens for left/right aligned blocks.

As a quick example - add an Image block, align it to left and make it 50% width, then turn it into a reusable block. The reusable block will now show as full-width even though on the frontend it's 50% and floated.

Is there a reason reusable blocks don't have the standard block's data-align attribute? I think adding it would fix all of it.

[mapk]

I'm removing the "Needs Design Feedback" label since it appears we're not in a rush on this, and number 2 above seems like the direction we want to go.

1. Making resuable block groups have the widest alignment of any of the children

[getdave]

@youknowriad I started looking into this as it somewhat limits the utility of the new Section Block.

Could you advise at a high level how it might be possible to dynamically set an align attribute on the core/block. I know how to query the _child_ Blocks and find the Block with the "widest" align setting but I can't for the life of me fathom how that could be passed to the Reusable Block.

[youknowriad]

@getdave I wonder if the solution here is not to "save" the attribute in the core/block but more something like by default show the reusable blocks as full-width containers. (Something very similar to the section block if they are aligned full-width I think)

[benoitchantre]

@youknowriad Could it be added to a future milestone?

[dbmpls]

I know I'm late to the conversation here, but from my testing it appears the global blocks are not put inside a wrapper, they are simply converted. Unless I'm really missing something, I think the solution is now simpler than it was when this was originally reported.

If you look at the html structure of a reusable block like "cover". The paragraph is wrapped in it's own div and has its own width styles applied. It does not depend on the parent block before OR after being converted to reusable.

When "cover" is converted to reusable it should simply retain its data-align attribute. This won't stretch out the paragraph, the whole block just continues to behave like it did before being converted. You can test for yourselves using the inspector and modifying the html.

In my testing, converting a block to a reusable block does not affect the structure of the nested blocks, it only changes the parent block... and it would be appropriate for it to keep it's styling from before being converted.

If you convert a wide image into a reusable block, it is now a wide image wrapped in a reusable block container. I.e. the image inside the container still has a wide alignment, but it is now constrained by the parent block, the reusable block container, which has the same max-width as any other normal block.

This doesn't appear to be the case any longer - The reusable block does not appear to be a wrapper, it simply converts the block that was selected.

I don't think we any longer need to force all reusable blocks to full width, or somehow detect the widest child... simply allow it to inherit the data-align attribute from the block that was converted.

[brettsmason]

Just wondered if ther were any plans for this?
I'd really like to use reusable blocks as I feel they could be really useful, but the visual inconsistency it creates causes confusion for clients. As a result they are rarely used.

[noisysocks]

Can confirm that this is still a bug. The next step is for a developer to explore one of the two options described in https://github.com/WordPress/gutenberg/issues/8288#issuecomment-440124315. @dbmpls raises an interesting point which is that the editor markup has changed considerably since this issue was opened and so fixing this may be easier than it once was.

[dsifford]

Dibs.

Let me know if someone already started working on this.

Edit: gonna be delayed til next week on this d/t having issues with wp-env on linux and might have to just home-roll my own env setup for the time being.

[dsifford]

In the meantime: just fiddling around in the css in devtools and it seems this can be resolved simply by adding the following to the css....

.wp-block.is-reusable {
  max-width: none;
}

Is there something I'm missing here that makes this solution not acceptable? cc @noisysocks

[noisysocks]

I think adding max-width: none; is what @jasmussen means by "1. Always making reusable block groups fullwide" in https://github.com/WordPress/gutenberg/issues/8288#issuecomment-439800898.

I'm OK with it but it doesn't provide the best experience when the block _isn't_ Wide or Full width. Here's how that looks:

[jasmussen]

I'm OK with it but it doesn't provide the best experience when the block isn't Wide or Full width. Here's how that looks:

I think it's okay in that it shows _the available space for content inside_.

[dsifford]

So how would you all like to proceed with this? Maybe just do the css fix first and then revisit for the "smarter" option that accounts for child block widths later?

I, too, am a bit concerned with the "smarter" option in that it seems like it would add more complexity to the editor where it doesn't need to be. But I'll leave that judgement call to you all.

[jasmussen]

Maybe just do the css fix first and then revisit for the "smarter" option that accounts for child block widths later?

If there's an easy CSS fix that addresses the issue and the only downside is the wide look shown above, then that seems worth trying first, as it doesn't preclude revisiting if we find it necessary!

[noisysocks]

In the medium to long term, I wonder if there's a way that we can indicate that a group of blocks is reusable which doesn't involve wrapping the blocks with a border. It looks very out of place now that G2 has eliminated most "block chrome".

[jasmussen]

I wonder if there's a way that we can indicate that a group of blocks is reusable which doesn't involve wrapping the blocks with a border

It does feel like for every border we've removed, the experience has gotten a little more pleasant, and _what actually has focus_ has become clearer.

However with both reusable blocks and template parts (be careful to not conflate the two!) I agree it seems prudent to expect some visual differentiation, simply just to indicate you're editing a global element. Doesn't have to be a border, could be something akin to spotlight mode, could be something else, and it might or might not work the same for both template parts and reusable blocks (even though they are very different). CC: @epiqueras just in case you have input.

[epiqueras]

@jasmussen I like the subtle styles David Lein mocked up recently.

We could also try just removing the left and right borders.

[strarsis]

As a workaround I currently have to assign max-width: none; width: 100%; to all reusable blocks (in editor styles of theme).