• lgladdy

• in reply to: Size limitations on media not removed when media overlay closed.
• August 31, 2021 at 9:47 am

@matthewpoll101 Thanks for the report. We’ve got a fix ready to go for this issue on Featured Images which should be out in the next (or one after) release.

I’ll add some testing for the image block too to make sure the fix applies there as well.

Edit: Confirmed that this should resolve the issue for image blocks too.

• lgladdy

• in reply to: Block 'Supports' not working as expected
• August 31, 2021 at 9:45 am

Hey @kandb,

Yeh – so it’s specifically that double wrapper that’s our main issue at the moment. We don’t get much control on the outer wrapper, that’s a WordPress default and our attempts to avoid applying those classes/styles there have caused issues. The inner “wrapper” comes from your template, and that’s where these styles should live – but because we need to render PHP to build your template, we can’t easily “live” update your template with the styles as you do something in the block editor, say adding padding etc.

Also, of course – someone could decide to put the styles somewhere deeper into the DOM of their template, so we can’t also just rely on the “outer” wrapper being the place where that should live. If we do stop the styles being applied on the WordPress outer wrapper, you’d have to wait for the AJAX request to re-render the template to see your changes, and this feels incredibly slow and “broken” vs native blocks.

Anyway! We’ll get the fix for specific issue of the editor “forgetting” when you’ve applied things like spacing in the next day or so, and figure out the way forward from there!

• lgladdy

• in reply to: Block 'Supports' not working as expected
• August 31, 2021 at 7:08 am

Hey @kandb,

Yeh – we think we need a little more work to get the CSS side of styles working correctly, so we’re going to roll back to how it worked in ACF 5.9.9 with this week’s ACF 5.10.2 patch – so this will fix your issue (but you’ll need to roll back your template to what you had for 5.9 with the raw WordPress internal code being sent to your template in $block['style'])

Our end goal is to pass valid CSS to the template in the $block['style'] variable, so you can just output it directly, but doing so in a way that doesn’t damage the block editor experience is proving tricky – as WordPress wants to apply it to a wrapper, but we want to leave it to your template to render.

• lgladdy

• in reply to: Block 'Supports' not working as expected
• August 30, 2021 at 7:37 am

Hey @kandb,

Thanks for the report here. We’re looking at how to best resolve this issue, whilst maintaining backwards compatibility.

Can I ask, did you first setup this block in ACF 5.10 or was it working in ACF 5.9 and the 5.10 upgrade broke it?

As far as we can see, the ACF 5.10 changed how some support properties are rendered. In 5.9.9, the raw WordPress markup was passed to your template, but in 5.10 it becomes valid CSS, which is obviously not backwards compatible for those users who coded for the raw data.

• lgladdy

• in reply to: Post Object filter won't retun html but return text
• August 30, 2021 at 3:55 am

Hey @toniojst,

We’re aware of the issue where the select2 field no longer supports any HTML – we’ll have this fixed in a patch in the next few days!

Thanks,
Liam

• lgladdy

• in reply to: ACF Latest Update Select Field with Stylized UI Not Rendering HTML
• August 29, 2021 at 1:05 pm

Hey everyone,

We’re aware of this issue should have it patched in a release in the coming days!

You’re right that it’s being escaped, but we’re going to allow some safe HTML back into select2 fields to solve this.

• lgladdy

• in reply to: wp_kses breaks select images
• August 28, 2021 at 8:57 am

Hey, thanks for the report!

We’re intended to release a patch next week that will allow safe HTML like this inside a select2 field.

• lgladdy

• in reply to: ACF & Yoast Seo Conflict Issue
• August 28, 2021 at 8:55 am

Hey everyone,

Do you also have WooCommerce installed with Yoast on these installs?

In 5.10.1, we had to work around a bug in WooCommerce where they’re loading a non-select2 compatible version of SelectWoo by mistake, but calling it select2. They’ve got a patch already merged to core for their 5.7 release – but until then, I think it’s possible that Yoast + WooCommerce leaves us a case where this could happen.

• lgladdy

• in reply to: acf_register_block_type display only commented data on website
• August 26, 2021 at 6:35 pm

Hey, how are you outputting the content?

That looks like you’re outputting $post_object->post_content without first passing it through apply_filters('the_content', $post_object->post_content)

• lgladdy

• in reply to: Post Object showing as [object Object] in select
• August 26, 2021 at 12:22 pm

Hey @matthias-wagnerfalkemedia-at,

ACF 5.10.1 has just been released. Could you confirm this solves the issue for you please?

• lgladdy

• in reply to: Post Object showing as [object Object] in select
• August 26, 2021 at 9:55 am

Hey @matthias-wagnerfalkemedia-at,

You are right that this is a WooCommerce conflict. They install a different version of select2 called selectWoo, and it has an issue with rendering templates: https://github.com/woocommerce/selectWoo/issues/39

We’ve got a workaround in testing right now though, and we should have a patch out for this shortly! I’ll let you know once it’s available.

• lgladdy

• in reply to: ACF Block preview html is sanitized in Gutenberg?
• August 26, 2021 at 8:07 am

Hey @twansparant!

This was a fun one to look into!

Turns out, React’s behaviour for tags like that will be false, so because you’re using JSX parsing for the block, it’s reading it as “false” and not showing it at all.

If you set them all to “playsinline=’true'” they will work correctly, apart from “muted”, which never appears in the DOM – but this appears to be a known issue with React, and the while the video will actually be muted, it won’t appear in the DOM: https://stackoverflow.com/questions/61510160/why-muted-attribute-on-video-tag-is-ignored-in-react

Hope this helps!

• lgladdy

• in reply to: Post Object showing as [object Object] in select
• August 26, 2021 at 7:28 am

Hey @matthias-wagnerfalkemedia-at,

Thanks for the report, we did make changes in 5.10 that could potentially cause this, but we’ve been unable to reproduce it locally – it could be caused by the browser loading a cached or old version of the acf-input.js file though.

Are you able to clear the browser cache and see if it’s still happening? Alternatively, if you could send us your field group export to [email protected], I’ll pick this up with you there and see if we can figure this out.

If you’ve go the issue happening on a publicly accessible site you’re able to grant us access too, even better.

Thanks for your help!

• lgladdy

• in reply to: ACF widget dont save data.
• August 25, 2021 at 4:12 pm

Hey @matib12 and @endcore.

We’ve just released ACF 5.10 which includes a fix for this issue! Please let me know if you continue to have any problems after updating.

• lgladdy

• in reply to: Javascript error when reordering in Post Object Repeater
• August 25, 2021 at 4:05 pm

Hey Everyone,

This issue (specifically, the conflict with Yoast) was solved in today’s 5.10 release! 🎉

More info in the release post here: https://www.advancedcustomfields.com/blog/acf-5-10-release-html-escaping-blocks-api-v2-block-preloading-and-more/

• lgladdy

• in reply to: Combine color picker swatches with theme.json
• July 14, 2021 at 5:33 am

Hey @proxxim, thanks for the suggestion.

You could do this now using getEditorSettings which includes the color palette, so something like the following js filter:

acf.addFilter('color_picker_args', function (args) {

    const settings = wp.data.select( "core/editor" ).getEditorSettings();
    let colors = settings.colors.map(x => x.color);

    args.palettes = colors;
    return args;

});

• lgladdy

• in reply to: Your site doesn’t include support for the "acf/block-name" block.
• July 14, 2021 at 3:51 am

@jonschr Yup! That seems great 🙂

And just for anyone else reading this thread, @hellmute’s issue seems to be different. I’ll update back here once we have a cause and resolution there too 🙂

• lgladdy

• in reply to: Your site doesn’t include support for the "acf/block-name" block.
• July 14, 2021 at 3:48 am

@jonschr Hey Jon, you’re right that ACF prevents itself from loading, but your call to the change the setting URL is being read by the “normal” install of ACF, and trying to load the assets from your included plugin as that is still set.

Your best bet would be to copy that detection logic into your plugin, then place the whole include and add_filter inside it.

• lgladdy

• in reply to: Your site doesn’t include support for the "acf/block-name" block.
• July 13, 2021 at 6:30 pm

Hey @jonschr, ACF 5.9.8 changed most of the asset paths, so the issue with your section plugin is a conflict between the bundled ACF 5.9.3 and the installed ACF 5.9.8.

Because you filter acf/settings/url to your path, that’s being applied to the installed 5.9.8 too, which is then trying to load 5.9.3 assets. This is likely to break a lot of things regardless, as even on 5.9.7 you’d have been loading 5.9.3 assets.

You should probably detect if ACF is already installed and active and not modify the assets URL if it is.

• lgladdy

• in reply to: Your site doesn’t include support for the "acf/block-name" block.
• July 13, 2021 at 5:55 pm

Hey @hellmute

Could you drop us an email to [email protected] with your block configuration and template file please?

In the mean time, I’ll see if I can reproduce this with your elodin-section-block repo @jonschr

• lgladdy

• in reply to: undefined function get_current_screen()
• June 5, 2019 at 12:47 am

A form of this bug has resurfaced in yesterday’s 5.8.1 release.

The new acf_is_block_editor function in api-helper.php should presumably also check if get_current_screen exists at the start (line 5051)

I fixed it with the following code:

function acf_is_block_editor() {
	if( function_exists('get_current_screen') && method_exists(get_current_screen(), 'is_block_editor') ) {
		return get_current_screen()->is_block_editor();
	}
	return false;
}

• lgladdy

• in reply to: api-helpers.php on line 846 error after updating
• November 5, 2014 at 8:08 am

It’s a simple bug with a simple fix, i’m sure Elliot will have 5.1.2 out the door very quickly, but if this is really affecting you,

https://gist.github.com/lgladdy/3d16dcf87c1cec4c4b6d

will help!