Critical error after update from 0.9.2.4 to 0.9.2.6
-
Hi there,
I’ve just updated the plugin from 0.9.2.4 to 0.9.2.6. The server went into an 503 error immediately. Because it was just a small update I thought I could do I without thinking about it.
After turning on the debug the error message was “Call to undefined function …” – WP was calling a theme function. When I downgraded the plugin to 0.9.2.4 the site went up again.The website specs:
– WordPress 6.9.4
– PHP 7.4.33 (maybe I should tell the customer to update it)For now, I’m not going to post any more updates. But maybe you can tell me whether the patch was faulty or if it’s due to the PHP version. There might be other users who are having the same problem.
Kind regards
Tanja
-
Hello,
Thanks for the feedback!
By any chance, do you have the entire error message? Because without it, it’s hard to tell what’s going on.
I’m constantly monitoring tickets, and since some time now (even during the previous 0.9.2.5 update) it’s pretty quiet. But it doesn’t mean a bug isn’t hidden somewhere. This is why the error message is important.
The 0.9.2.5 & 0.9.2.6 versions include a lot of code cleanup and deprecated ACFE functions. If a developer still use one of them, it will work and log a “warning message” in the debug log, but not throw an error.
Maybe you could try to clone your website on a local/staging environment and update it there again, see if you can still get the message? Duplicator is a nice and free plugin to do that easily.
Thanks!
Regards.
Hi Konrad,
thanks for your quick answer. I did some homework. The error message was:
Fatal error: Uncaught Error: Call to undefined function themename__get_hero() in /…/themes/themename/parts/element-hero.php:24
Stack trace:#0 /…/wp-includes/template.php(816): require()#1 /…/wp-includes/template.php(749): load_template('/www/htdocs/w01…', false, Array)#2 /…/wp-includes/general-template.php(206): locate_template(Array, true, false, Array)#3 /…/wp-content/themes/themename/header.php(179): get_template_part('parts/element', 'hero')#4 /…/wp-includes/template.php(814): require_once('/www/htdocs/w01…')#5 /…/wp-includes/template.php(749): load_template('/www/htdocs/w01…', true, Array)#6 /…/wp-includes/general-template.php(48): locate_template(Array, true, true, Array)#7 /…/wp-content/themes/themename/front-page.php(1): get_header()#8 /…/wp-includes/template-loa in /…/wp-content/themes/themename/parts/element-hero.php on line 24
Unfortunately I opened this thread before I did some research. Eventually the newer version of ACF Extended just triggered a fragile include order in our theme. I explored the theme and got some information:
“A few ACF JSON files in the theme still use the old structure with top-level keys such as acfe_autosync, acfe_display_title, acfe_form, etc.ACFE 0.9.2.6 now expects these to be formatted as field_group[‘acfe’][‘autosync’], etc. If ACFE processes the JSON files during loading/syncing and encounters the old structure, this can cause an error that interrupts the bootstrap process—before frontend-functions.php is loaded.”
Means I have to do some legacy upgrades in our theme.
Thank you again, Konrad!
Hello,
Oh okay I see, that’s a sneaky one. That would make sense.
In fact, since ACFE 0.9.2.6, Field Groups ACFE settings have a new cleaner structure.
If you need to use the old field group settings structure, you can add the following code in your theme’s
functions.php:add_action('acf/init', 'my_acfe_modules');
function my_acfe_modules(){
// ACFE 0.9.2.6: Field group acfe settings structure change
// new structure: $field_group['acfe']['autosync']
// old structure: $field_group['acfe_autosync']
// with this code, the old structure remain available with the new one:
acf_update_setting('acfe/compatibility/legacy_field_group', true);
}This will make the
$field_group['acfe_autosync']available again, just like before (alongside the new structure), and let you migrate slowly when needed.Note: you can safely use this code in previous ACF Extended versions, it won’t break anything. It’s only checked in the newest version. So you can keep it during your upgrade/downgrade tests if needed.
Let me know if that helped!
Thanks!
Regards.
Hello,
I’ve read again the description that follows your error message which seems written by an LLM:
ACFE 0.9.2.6 now expects these to be formatted as field_group[‘acfe’][‘autosync’], etc. If ACFE processes the JSON files during loading/syncing and encounters the old structure, this can cause an error that interrupts the bootstrap process—before frontend-functions.php is loaded.”
I just wanted to be extra clear:ACFE doesn’t expect the new structure, either in code or in existing JSON files. Compatibility is maintained out of the box internally, no matter which structure is in place. Your JSON files may have the old structure, it’s not an issue. Your field group will be found and your fields too.
The code I shared with you, with the setting
acfe/compatibility/legacy_field_group, just re-add the old structure in the$field_grouparray in case a developer need them. For example if you manually retrieve the field group in your theme code, and need to use it for some reason. This is simply for developers convenience.Thanks!
Regards.
Hey Konrad,
Yes, that’s what the AI analysis showed. Sorry, that wasn’t quite right. I also did a little Googling. The old structure is still in those few ACF field groups — I noticed that too, and I would have tried that.
If I understand you correctly, I can go ahead and paste your code into functions.php for now and see what happens. If the error persists, I’ll look for the cause elsewhere.
Sorry for the inconvenience; we’ve taken over the website from someone else and aren’t yet familiar with all the details or how everything works. I’ll let you know as soon as I find out more.
Thank you!
Tanja
Hello,
Yeah, in all cases you can use the code I shared.
It will has no negative impact other than making the Field Group array less “clean”. But that’s secondary at the moment.
Let me know if you found something.
Regards.
Hi,
just a quick follow-up: after further investigation, the issue turned out to be caused by several outdated implementations in the theme.
A theme plugin was accessing settings/capabilities before the permissions system was fully initialized. The newer version of ACF Extended triggered a recursive loop that eventually exhausted server resources.
After updating the affected theme code, the issue is resolved.
My apologies for the confusion, and thank you for your time and assistance.
Kind regards
Hello,
I’m glad to hear you managed to fix the issue!
By any chance, do you have more details about what was triggered? The initial error you shared was about a missing function, and not an inifinite loop/exhausted memory:
Fatal error: Uncaught Error: Call to undefined function themename__get_hero()If you have any further details I would be curious to know about it.
Thanks!
Regards.
Hi Konrad,
Posting here since new topic creation seems restricted on my account – apologies, this is unrelated to the original 0.9.2.4→0.9.2.6 issue, but I wanted to flag a separate, newly-found bug with ACFE + the latest SCF release.
Since SCF 6.9.4/6.9.5, all ACFE-rendered front-end forms fail validation on submit with: “SCF could not validate this form because its security information is invalid or has expired.”
Root cause: SCF 6.9.4 added a new signed-grant system for
acf_form()submissions – the rendered form must emit a_acf_form_meta[]token, checked inverify_form_meta()/validate_save_post_authority()inform-front.php. ACFE’s Forms module renders under its own screen (_acf_screen=acfe_form) and doesn’t appear to emit this field, so every submission is rejected immediately (confirmed by capturing the actual failed AJAX POST –_acf_form_meta[]is absent).Environment: SCF 6.9.5, ACFE 0.9.2.6 (free), WordPress on Pressable.
Happy to open this as its own topic if/when I can, or provide more detail – just wanted to get it on your radar given how active you are here.
Thanks,
Perica
You must be logged in to reply to this topic.