When an acf block is set to align right or left, it is often impossible to select.

[maartenhunink]

Since WP 5.5 when I click on an acf block that is aligned to the right or left, nothing happens. It is sometimes possible to select it by clicking on a very thin area above the block. This line becomes blue when the block is selected as shown below.

I did a bit of diggin in the html/css and when comparing the html markup of an ACF block (which is aligned right), with a core block like the image block (which is aligned right) I noticed the markup is different.

The ACF block adds an <div class="wp-block" data-align="right"> inside of the main .block-editor-block-list__block div. While the core block wraps that same <div class="wp-block" data-align="right"> around (outside) of the main .block-editor-block-list__block.

After wraping the <div class="wp-block" data-align="right"> around the ACF block the block becomes selectable again and it now also shows the correct blue border/outline again.

I've tested this on a fresh WP install with ACF 5.8.13 and ACF PRO 5.9 RC1 without any other plugins or styles.

I hope this is somehow helpful.

[elliotcondon]

Hi @maartenhunink - Thanks for the bug report and investigation work!

I've just replicated the same issue with a core "Latest Posts" block, which leads me to believe this may be a widespread bug affecting all dynamic (and possibly static) block types. Would you mind testing this too?

[maartenhunink]

Hey @elliotcondon - I believe that is correct, good catch. I'v tested it with other core blocks (latest comments, calendar, categories) and they all have the same issue.

I assume somebody else must have reported this to the WP team by now. But searching through https://core.trac.wordpress.org/tickets/latest I couldn't find anything similar. Would that be the place where this bug would be reported? I am not familiar (yet) with reporting bugs to WP core.

[elliotcondon]

Hi @maartenhunink Yep, posting on either the core WP track or the Gutenberg GitHub repo are the two ways to pass on bug reports.

[maartenhunink]

Thank! Issue has been created on the Gutenberg Github repo: WordPress/gutenberg#24653

[maartenhunink]

Dear @elliotcondon, this issue seems to have been fixed for the core WP blocks, for instance the Latest Posts block. But it's still broken for ACF blocks. I found another issue related to other non-core blocks which seems to report the same problems: WordPress/gutenberg#25088

I don't know if there is anything which can be done from ACF side to fix this, might need to be done in Gutenberg. But would really appriciate it if you could have a quick look into it. Thank you!

[elliotcondon]

Thanks @maartenhunink. I'll do my best to investigate this.

[maartenhunink]

Thanks @elliotcondon! I haven't tested this much yet, but for now it seems I fixed it with some simple scss.

[data-type^="acf/"]{
	&[data-align="right"], &[data-align="left"]{
		.wp-block{
			@include clearfix;
			height: auto;
		}
	}

	&[data-align="right"]{
		float: right;
	}
	&[data-align="left"]{
		float: left;
	}
}

I'm using a clearfix mixin from bootstrap.

[kylelarkin]

Hi @elliotcondon, I'd like to follow up with a little extra info I've noticed dealing with this same issue.

I'm not sure how Gutenberg is dealing with it but on a core block like a pull quote, if a pull quote is inserted into the editor without alignment, its top level wrapping element in the .block-editor-block-list__layout div is a figure with a class of 'wp-block-pullquote'.

As soon as an alignment is selected for the pull quote, Gutenberg wraps that figure in a div with a class of wp-block and a data-align=right attribute.

It's this extra wrapping element that lets the block float right or left but keeps its Gutenberg controls attached to the block.

With an ACF block when alignment is applied, it's only applied to the top level block wrapper div which has the controls attached to it.

There's something about the extra wp-block wrapper on the aligned pull quote that is allowing the block to properly float without messing with the controls.

I think these issues have been documented here: WordPress/gutenberg#24721 (comment)

[elliotcondon]

Thanks @kylelarkin. This information aligns nicely with the bug report and findings so far. I hope we can figure this out causing any backwards compatibility issues.

[wpf500]

Thanks for the CSS fix @maartenhunink, very useful.

A couple of additions:

1. Set position: relative on .acf-block-component so you can click on the floated block
2. A hacky margin calculation so the blocks don't float all the way to the edge. It's very rough and you can't make it line up completely because viewport width CSS units don't take into account the scrollbar so I went with slightly under (48vw) as it looked nicer. It also assumes you are using the 840px width that .wp-block elements are given by default

So my code is:

[data-type^="acf/"] {
  &[data-align="right"], &[data-align="left"]{
    .wp-block{
      &::after {
        content: "";
        display: block;
        clear: both;
      }
      height: auto;
    }
  }

  &[data-align="right"]{
    float: right;
    @media (min-width: 1000px) {
      margin-right: calc(48vw - 420px);
    }
  }
  &[data-align="left"]{
    float: left;
    @media (min-width: 1000px) {
      margin-left: calc(48vw - 420px);
    }
  }

  & > .wp-block > .acf-block-component {
    position: relative;
  }
}

Screenshots with a core image block for comparison:

Before

After