RIP Advanced Custom Fields!
So I have 100+ websites that I apparently now have to check, without any proper warnings. Very professional.. NOT.
Downgrading to 5.11 did not work and now I have to look into 100+ production sites.
For example, the code below does not work anymore. It shows empty values. Fields are registered via the WP admin (just the native ACF way). No registration via PHP involved.
What’s wrong?
<style>
<?php if(get_field('header-achtergrond') == "image"):
$img_desktop = wp_get_attachment_image_src(get_field('header-image'), 'img-1920-1080');
$img_mobile = wp_get_attachment_image_src(get_field('header-image-mobile'), 'img-750-1334');
?>
@media only screen and (min-width: 720px) {
.header-bg-img { background-image: url(<?php echo $img_desktop[0]; ?>); }
}
@media only screen and (max-width: 719px) {
.header-bg-img { background-image: url(<?php echo $img_mobile[0]; ?>); }
}
<?php endif; ?>
</style>
@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?
What does: $test = get_field('header-achtergrond'); echo $test; output?
Assume the field has a value? Is it in a loop or does it need a page/post ID?
Does your conditional code get triggered?
`if(get_field(‘header-achtergrond’) == “image”):
echo ‘hello, we get this far!’;
endif;
I’ll try to downgrade further, but this is going to cost me days either way.
In my case, that code is in header.php, before <?php wp_head(); ?>
<!-- <?php $test = get_field('header-achtergrond'); echo $test; ?> -->
does output this:
<!-- -->
In other words: nothing.
Can you remove the html before and after <!– is used to comment out, which may explain seeing nothing
@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?
@jarvis Well I didn’t want anyone else to see me testing the output on the front end, so that’s why I commented it out. I checked the source and it’s showing nothing.
Apologies – that makes sense.
So <?php $test = get_field('header-achtergrond'); echo $test; ?> returns nothing.
Where should the get_field pull data from, is it the page/post your own or an options page or somewhere different?
If its the post, can you add the post ID in question into the get_field request for $test? Does that work?
@hwk
Got around to setting up a test site 🙂
I am not using have_archive – loop.
I enable debug mode and can confirm that there is data in the field on the archive page.
I wonder if ACF sees the archive page as an option page that is outside acf scope and that I therefore should use the wordpress get options function instead?
I can give you access to the site if you want. Just send me a mail 🙂
After a discussion with @johannesalfanova-dk and after checking its website, the problem came from the get_field() that was used in the acf/init hook before the local field group PHP registration. So ACF 5.11.1 wasn’t able to retrieve the field and the value.
Changing the hooks priority fixed the issue (registration first and then the get_field() call).
Regards.
Hey Everyone,
As you’ve probably already seen, we made some significant changes in the ACF 5.11.2 release which should help mitigate the majority of issues you’ve been experiencing in ACF 5.11 and 5.11.1.
You can view full details in the changelog (https://www.advancedcustomfields.com/changelog/) and the acf field functions documentation (https://www.advancedcustomfields.com/resources/acf-field-functions/).
When I use get_field(field, custom_post_id) it returns null and is breaking the site. I tried downgrading to 5.10 but still facing the same issue.
I am running multisite and the get_field is being called by
a callback from REST endpoint i.e register_rest_route() which is initialised by child theme’s functions.php.
Please help!
