ACF Pro 5.10.1 (5.10?) bug when saving a block in editor mode

[ideag]

Hi!

We ran into a bug in ACF Pro 5.10.1 this morning.

I've made a screen recording of what we see here: https://www.youtube.com/watch?v=wZ9WivtOvxc

In ACF Pro 5.10.1, if you open an ACF block to Edit it, save the post and then reload the page/open it again, it comes back broken.

It looks like ACF thinks it is in preview mode, renders the acf-block-preview div, but then renders all the editor fields inside it.

It becomes an obvious issue if you have some custom css on the .acf-block-preview class, i.e. pointer-events:none;

But also it starts breaking down some more as you go along, ACF starts showing the "Edit" button when you are in editor view, and preview button when you are in preview screen (I haven't filmed this part yet, found it afterwards.)

I was able to replicate this on a fresh site with just WP Core 5.8 and ACF 5.10.1 so it is definitely not 'environmental'.

[lgladdy]

Hey @ideag, Cheers for the report.

As a workaround, you should be able to click preview and then edit and it'll sort itself out right? Or does the button just do the inverse of what it should do?

I believe blocks are supposed to load the last view you were in, so the bug here is that the "mode" button is in the incorrect state - but it is loading the "correct" view based on what was displayed when you last saved the page.

[ideag]

so the main issue is that editor UI gets loaded into the .acf-block-preview class. So the view is "correct" but it is inside of the block preview for some reason.

[ideag]

See here:

[ideag]

and as for buttons, it shows an Edit button, but as you are in edit mode already, when clicking it toggled you into preview mode. If you are in preview, the preview button is showing and when you click it, you get to edit mode.

[lgladdy]

Hey @ideag - Yeh, I'm pretty sure the two are linked, ie: we're storing a "mode" state that is wrong, and that mode state decides what wrapper to put around the content, and what button should be displayed, so hopefully this is a simple fix!

[ideag]

🤞 that it is. Can't really downgrade this because of the security fixes, and while I can navigate around this myself, I can't train a bunch of content editors in various timezones to do that as well. Any chance of back-porting the security fixes to 5.9 while this gets sorted?

[lgladdy]

@ideag You could downgrade to 5.9.9 and enable the experimental constant from 5.92 to keep the HTML escaping.

Either way, I think we're hoping to get a 5.10.2 release out next week with a few little fixes in, and we'll aim to get a fix for this issue in there.

[ideag]

@lgladdy does that cover https://wpscan.com/vulnerability/f322619a-e85d-4931-8785-eb9cf30cef7f as well?

[lgladdy]

@ideag Unfortunately not - that's a separate issue that was first fixed in 5.10.

We'll try and get this fix out for you ASAP.

[ideag]

Then downgrading is not an option for me. If I knowingly downgraded 200+ sites to a vulnerable version, our security guys would skin me alive :)

Really appreciate quick reaction to this!

[mattgrshaw]

Closing this one since we've released 5.10.2 today which addresses this issue.

Please give that a try and let us know if you run into any further issues @ideag!

[ideag]

Hi. Sorry for the late reply! Yes issue seems to be fixed. Thanks for the quick work!