Core Image block doesn't use align support property for Block Alignment

[TeemuSuoranta]

Describe the bug
Registered blocks' settings can be altered via JS hook blocks.registerBlockType. This can be used to limit alignment options for various default blocks. If you try to limit image block's align options, the default align settings are rendered with the new altered settings – you'll end up with two align UIs.

To reproduce
Steps to reproduce the behavior:

1. Add JS file to theme "editor-gutenberg.js"
2. Include it to Gutenberg

add_action('enqueue_block_editor_assets', function() {
  wp_enqueue_script('my-gutenberg-scripts', get_stylesheet_directory_uri() . '/dist/scripts/editor-gutenberg.js', ['wp-i18n', 'wp-blocks', 'wp-dom-ready'], '', true);
});

3. Filter out unwanted align options (ref: https://developer.wordpress.org/block-editor/developers/filters/block-filters/#blocks-registerblocktype)

wp.hooks.addFilter(
  'blocks.registerBlockType',
  'my-theme/filters',
  function(settings, name) {
    if (name === 'core/image') {
      return lodash.assign({}, settings, {
        supports: lodash.assign({}, settings.supports, {
          align: ['wide'],
        }),
      });
    }
    return settings;
  }
);

Expected behavior
Default alignment dropdown options are replaced with filtered ones.

Screenshots

(Two UIs for alignment)

Root of problem

• The image block doesn't use align support options like other blocks https://github.com/WordPress/gutenberg/blob/master/packages/block-library/src/image/index.js

[paaljoachim]

Hi @TeemuSuoranta Teemu

Thank you for creating this issue!
Is it still valid?

@WordPress/gutenberg-core

[TeemuSuoranta]

I'll test this again next week and get back to you!

[TeemuSuoranta]

I re-tested and bug still exists with WP 5.6. Bug also exists if Gutenberg plugin is activated (9.8.2).

[paaljoachim]

Thank you for checking Teemu!
I am hoping that the Image block will be reworked very soon. So that the various issues will be fixed.

[talldan]

My understanding is the image block doesn't use the standard block supports option for alignment, it has its own implementation. That explains why two dropdown menus appear, the code above isn't modifying but adding.

I don't know the history on why that's the case. There's some discussion here - #20650.

[TeemuSuoranta]

I looked the code too that much that for whatever reason the image block is implemented a little bit different in this regard. If this is intentional, there could also be some kind of cleaner filter hook as this is somewhat common use case for custom sites or possible some public themes.

[schutzsmith]

Any update on this? I'm running into the same issue and would love to find a fix.

[alpopp]

It would be great to get the image block to use the standard block supports here for alignment.

[souricardomaia]

Hey there, any update about this?

[fabiankaegy]

@carolinan I'm reverting your classification of this ticket as Help Request. I'm not sure Bug is the correct label either but this is an inconsistency that has come up again and again.

[TeemuSuoranta]

I understand that it might be hard to classify. The way I'd see it is:

A) If all core blocks' alignment options should be filterable (themes or plugins should be able to alter them) this is a bug because it causes an UI issue of double UI for alignment.

B) If all core blocks' alignment options are not meant to be filterable, this is not a bug because as a developer I should not be able to do this for image block.

[fabiankaegy]

For clarity's sake, the issue here is that the Core Image block doesn't use the align support option to add its alignment controls. Instead, it manually adds the BlockAlignmentControl component in its edit function.

gutenberg/packages/block-library/src/image/edit.js

Lines 363 to 368 in a7f4df0

	<BlockControls group="block">
	<BlockAlignmentControl
	value={ align }
	onChange={ updateAlignment }
	/>
	</BlockControls>

As @talldan already mentioned there is some discussion about the historical reasoning behind this inconsistency here: #20650

---

Also after doing a bit of testing myself I have not found any inconsistencies in the markup if the default alignment support is used in place of the custom approach here. The classes are identical.

The only thing that seems to be specific to the image block is, that the width and height attributes get reset to undefined whenever the block alignment gets updated to be wide or full:

gutenberg/packages/block-library/src/image/edit.js

Lines 272 to 280 in b1f1d56

	function updateAlignment( nextAlign ) {
	const extraUpdatedAttributes = [ 'wide', 'full' ].includes( nextAlign )
	? { width: undefined, height: undefined }
	: {};
	setAttributes( {
	...extraUpdatedAttributes,
	align: nextAlign,
	} );
	}

I'm not sure how this could get replicated when using the default supports system.

[fabiankaegy]

I just ran into another oddity with this custom alignment dropdown. When you change the default value of the align attribute to wide for example this should work as it does on the Media & Text Block.

However, there is one quirk here that causes a block deprecation to happen instead. When the align none option is selected from the dropdown the align attribute gets set to undefined and therefore the setting does not get saved. In the standard alignment dropdown, this does not happen. Instead, the none option gets saved as an empty string and therefore serialized and saved properly.

So currently this code:

function modifyImageBlockOptions(settings, name) {
	if (name !== 'core/image') {
		return settings;
	}

	return {
		...settings,
		attributes: {
			...settings.attributes,
			align: {
				...settings.attributes.align,
				default: 'wide',
			},
		},
	};
}

addFilter('blocks.registerBlockType', 'modify-image-block-options', modifyImageBlockOptions);

results in there being a deprecation error when you save an image where the alignment was manually set to "None"

[jackmakesthings]

Any progress on this? It would be really useful.

[karmatosed]

I am just floating up this is still an issue seeing, are others, specifically around the oddities @fabiankaegy outlines.