Hey Rasso,
Thanks for the report here, I’ve confirmed the behaviour you’ve described.
We’ll look into this ASAP and I’ll get back to you once I have a fix or workaround.
@eaglejohn Any chance you could create us a temporary admin user on the site in question and email details over to [email protected]? I’m happy to login and take a look!
Your code there should be fine – is it possible a you’ve got a pre_get_posts query filter somewhere that is stopping ACF being able to load data about that field?
@eaglejohn Downgrading to 5.10.2 will solve the issue, or you can deploy the workaround fix at the bottom of https://www.advancedcustomfields.com/resources/acf-field-functions/ as a quick fix.
That said, your code there should be fine. Where abouts is that code? Is it in a template file, or a filter somewhere?
@floodlightdesign Hey, we updated the documentation at https://www.advancedcustomfields.com/resources/acf-field-functions/ to include a sample drop in function which will revert the functionality to the old unsafe output if you’re looking for a quick drop in fix.
@johannesalfanova-dk Thanks! I’ll let the ACF Extended developer know and see if we can figure out what’s going on here 🙂
@johannesalfanova-dk Are you having issues outputting those values on archive pages, or getting the data somewhere else in your code?
Hey @nickfmc,
I’ve just tested this and it’s working okay for me. Could you share your block definition code (specifically the supports key)
Hey @retroriff,
Where about is your code that does the get_field? Could you drop us an email to [email protected] with your code for that, and we’ll take a look?
The chances are, that code is happening before ACF has been initialised, and so ACF doesn’t think the fields exist.
Hey @cbrady23 – Yup, that’s likely to be the cause. If you wrap your code inside a hook that is acf/init or later, you should be okay! But please let me know if you need any further help!
Hello,
In @benjamin74’s case, the issue was they were using get_field in a plugin but not wrapped inside an action hook – so it was executing as soon as WordPress loaded the plugin’s php file, before ACF and WordPress had initialised properly.
This “worked” prior to 5.11, but incorrectly. Because ACF had no awareness of the field, it returned the raw data from the database without any processing or formatting, or obeying any options defined on the field settings.
I’m pretty sure the only places where this can happen are in a plugin, or in a theme’s functions.php where you get_field is being called before the “acf/init” action, so ACF is not correctly loaded. In the case of functions like acf_add_options_page, or acf_register_block_type, our sample code includes the requirement to make sure acf/init has happened – but as get_field and the_field are “template” code, the vast majority of instances of their usage is in templates – where you don’t need to worry about making sure WordPress and ACF is fully initialised already – we’ll make sure the documentation is clearer about this for the future.
Hey @ado-mic,
Could you confirm your ACF version where this is happening? Could you also record a screencast of the issue happening, as I’m not able to reproduce on the latest version on ACF.
We did make some changes in ACF 5.10 around media library errors to fix this in some cases, so it’s possible your issue is already resolved.
Thanks!
Liam
Hey @andreabaino, we’re aware of this issue and have a patch prepared for release this week. Sorry for the inconvenience!
@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.
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!
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.
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.
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
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.
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.
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.
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)
Hey @matthias-wagnerfalkemedia-at,
ACF 5.10.1 has just been released. Could you confirm this solves the issue for you please?
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.
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!
Welcome to the Advanced Custom Fields community forum.
Browse through ideas, snippets of code, questions and answers between fellow ACF users
Helping others is a great way to earn karma, gain badges and help ACF development!
We use cookies to offer you a better browsing experience, analyze site traffic and personalize content. Read about how we use cookies and how you can control them in our Cookie Policy. If you continue to use this site, you consent to our use of cookies.