Change default Wide width alignment for Media & Text block to normal width.

[paaljoachim]

I am just about to reply to this support issue https://wordpress.org/support/topic/make-media-and-text-block-normal-width-not-wide-or-full/

If I have understood it correctly the person is asking how to make Media & Text the standard same width as other blocks.

I am about to tell him that he needs to turn off the initial default Wide Width:

Then have no alignment width selected. As no alignment selected is the same as normal width.

I would also suggest having a Normal width alignment. So that a user can select Normal width to see that they are using the standard width.

ps
Normal width is really not a good word. It could instead be default/standard width.
Right now deselecting width is the same as = default/standard width.

EDIT:
Could be something like this:

Advantage:
There is an default alignment visible in the UI alignment options popup.
Showing that there is an alignment that starts out as default and the user can then just change to any of the options available.
There is always one alignment selected. One can not turn off all alignments.
As turning off alignment is really outside the consistency in choosing which alignment to use.

The wording as I thought about it is the page content width.

[kurudrive]

I think so too!!
I have been used gutenberg before WordPress.5.0 but I noticed can use default width today!!
Long long and so long time, I had thought for Media Text Block is can use to wide or full only.

[VonJot]

I fully agree. In all combined blocks (not only Text&Media, bus also 2-columns etc) this is the DIV class:
"wp-block-media-text alignwide has-media-on-the-right is-stacked-on-mobile"
The "alignwide" is the culprit. If you remove that the original layout is restored. So yes, PLEASE, revert this horrible addition, or embed, as the OP stated, a manual selection for default!
This is the realtime effect... The image should be place INSIDE the template. No way to alter this.

[Gray-Stone]

I run into the same issue, and luckly I found your post and issue on this before spending too much time changing the CSS. I didn't even though not having alinewide is this easy.

So please change this feature to something more understandable.

[paaljoachim]

Joen @jasmussen I have a feeling we have earlier discussed this but I thought I would bring it up with you again.
Thanks!

[jasmussen]

I don't personally have a strong opinion here. It seems like a PR can fix it.

[paaljoachim]

Adjusting my initial idea to create a consistency with other blocks.

Example. Adding a Group block or Columns block starts out with no alignment selected. One has to select either Wide width or Full width for the Group block to change alignment.

---

Back to the Media & Text block.
It should start out with no alignment selected so the user sees the default content view.

Then selects to either use the default content view or go with Wide width or Full width alignment.
This creates a consistency with other blocks.

[getsource]

Have been looking into/working on this one.

Some existing tests (here's one example) and blocks have no align set at all, but have the alignwide class. This also looks to be the case in at least one of core's bundled block patterns. I'm assuming this means that it's something that exists in the wild as well, but haven't dug yet.

If I remove the wide default from block.json, then when those blocks get loaded in the editor, the alignwide class gets set in an attribute when it is loaded, something like this:
<!-- wp:media-text {"mediaType":"image","className":"alignwide"} -->

So, I'm looking for the best way to fix that. Currently, checking whether it would work to create a deprecation to handle adding setting align to wide when the alignwide class is used and align isn't set.

Any other recommendations/ideas welcome.

Related: #16365

[getsource]

I've been thinking about this on and off since the previous comment.

From what I can tell, wide was picked by design here.

The primary issue seems to be that it's unclear to users that alignment can be removed/cleared, which I don't think would be solved by changing/removing the default on this block.

If I understand properly, any block that has a default other than "no alignment" would have similar UX difficulties.

Unless there's a change of mind over what the best UX would be for the default alignment on Media & Text, I think it's probably better to address the issues with "unselecting" the alignment.

See: #30782 and the mockups there for another example of user confusion/lack of discovery of the feature, and some more ideas of how to change the UX.

What do you think?
cc: @jasmussen

[jasmussen]

I think I may have been the source of those original mockups! Yes, I do think that there could be a space for adding an explicit "no alignment" option which is shown as toggled by default in cases like these. The option was explored as being added back in context of making it clearer that wide and fullwide alignments need theme support, and perhaps even in context of CSS-grid-based positions as superficially discussed in #16998.

Looking back at those mockups, the only thing I'm waffling on is the help text that says "max 720px wide". Upon further reflection, we don't really add per-menu item help text like that in any other menus, so we probably shouldn't do that here either. Help text in menus, such as in the beginning or at the end of the menu such as what you see in the tools dropdown, can be fine to add if necessary.

[paaljoachim]

This PR: Show "none" as an alignment option and use contextual text to clarify settings
is somewhat associated. #34710

[getsource]

Now that #34710 has landed, is this still necessary?

My understanding behind this ticket is that the primary issue was that the alignment setting was unclear, because it wasn't obvious that the alignment was set and could be "unset".

Now that it's possible to choose "none", and it's intended functionality for Media and Text to default to "wide", I think the question is: Is there a user benefit to setting it to "none" by default, or is "wide" still the best user default?

I'm leaning towards closing this, but thought I'd check in on what folks thought first.

[paaljoachim]

Hey Mike @getsource

I believe we can go ahead and close this issue. As we now have a "None" width alignment.

Closing issue. Please reopen if need be.

[cbirdsong]

I think it's odd for Media & Text to default to something other than "none". It always trips me up when I use it, and I think it's the only block like this?

[tedw]

FYI if you create a Media & Text block within a column the width button goes away, but the Media & Text block still has the alignwide class in the markup. This could cause issues for theme developers who may not be expecting this behavior (like me 😄).

It would be nice if the alignwide class was removed when nested in a column, or if the width button was left visible so authors can change it back to “none.” My current workaround is to create the Media & Text block first, setting the width to “none,” then move it into a column.

[paaljoachim]

I am reopening this issue as I came across it again. Even made an issue without realizing I had this old issue.
#44352

[paaljoachim]

Default value today is Wide width. Default value should start out with None as width.
It would be helpful to have a developer look into this issue. Thanks!

[jasmussen]

It seems fine to default to none.

[paaljoachim]

I will go ahead and add the label good first issue.
@scruffian Ben. Perhaps it is something you can look into?

[paaljoachim]

Removing the Good First Issue label as @Mamaduka mentioned that it might require block deprecation.

[paaljoachim]

I just received an e-mail from a client asking me how to adjust the width setting for the Media & Text block. I have earlier told him how but he had forgotten. So I checked this issue to see if there has been any movement. I see that @carolinan Carolina has begun a PR which is in draft mode.
#46971

Thank you Carolina! I look forward to having this adjustments added to the Gutenberg plugin and later in core.

[carolinan]

@paaljoachim I have tried indeed, but I am still unable to solve the issue with the deprecation that was mentioned already in 2021. 😢

[paaljoachim]

I will ping @talldan @aaronrobertshaw as they might have some advice regarding depreciations.

[aaronrobertshaw]

Thanks for the ping 👍

At a quick glance, I suspect we need a deprecation with the original attributes definition (including the wide default for align), then migrate the block's actual attributes to set the align value to wide (where it was previously unset being the default). The deprecation would probably also require the isEligible callback.

I can take a closer look at #46971 tomorrow.

[carolinan]

#46971 doesn't include the deprecation; I never pushed it as part of the draft pr because it wasn't working. Feel free to ignore it; if there is an alternative, I will close it.

[aaronrobertshaw]

I never pushed it as part of the draft pr because it wasn't working.

@carolinan Can you elaborate further on how it wasn't working? Was the approach taken similar to my earlier suggestion?

I'd like to make sure there isn't something I'm missing and causing us to retread the same old ground.

[carolinan]

I tried to implement it according to yours and Mike's comments, but I could not get the migration to work. It checked for the class name and set the alignment conditionally,... but it was never actually set. I think it was the implementation, not the idea.

[aaronrobertshaw]

Thanks for clarifying 👍

I'm digging into the block's deprecations now. It might take a little while for me to grok it all given the lack of comments and the mix-and-match attribute objects.

I've been working on my own custom branch so far but if I get something that works I can publish it and you can decide whether to roll it into yours or iterate on it separately.

[aaronrobertshaw]

@carolinan I've run out of time today but have pushed a draft PR (#48404) that you might be able to work from.

It needs more testing in terms of ensuring all the deprecations are working as expected and that I haven't missed anything. Hopefully, it helps. If you notice any issues with it we can continue the discussion over on that PR.

[talldan]

I remember some previous challenges trying to change a block's default value. IIRC, the problem is that because the default value isn't serialized it's difficult to preserve the alignment for existing 'wide' media and text blocks. A migration will change them all to 'none'.

For the group block, this PR used a default block variation to change the default layout value - #44176. I think that works because it only applies the new default to blocks as they're inserted.

[aaronrobertshaw]

Thanks for the heads up @talldan 👍

All the more reason to give #48404 a thorough test and review.

The existing blocks that were defaulting to wide alignment have alignwide in their CSS class list. If the default is none the saved post content for the existing blocks would be invalid, triggering the deprecations to run. The new deprecation would have the old wide default so its save function would match the existing serialized HTML. The align attribute can then be set to wide.

What I was looking to test when I get back to this was ensuring that new blocks added don't falsely trigger the deprecation. The updated primary block fixture (which defaults align to none) appears to parse attributes correctly.

I could well be missing something and happy to change the approach if needed.

[paaljoachim]

Awesome!
A huuuuge thank you to everyone involved in getting the Media & Text block alignment set to None.
Thank you, thank you and very thank you!