Hey @hogash! How's it going?

Thank you for submitting this issue! 🙏

I'm going to have to investigate it further. Can you please share the field type used, and its configurations so we can reproduce it on our side?

Kind regards

Hey Nick, hope you're doing well too! :)

I just used a color picker field but I don't think that was too relevant.

I managed to partially replicate the error on a clean site ( Elementor + Pro + Hello + ACF + Woo ) but not the error that's blocking the editor, instead it blocks the preview.

I recorded a video here of what I did https://d.pr/v/PbZ2M7 . Basically embedded a template inside the header, in which I've added a widget that lists some terms ACF fields data ( the widget is custom, just to use get_terms).

And here's the entire website exported with All in one Migration https://d.pr/f/0p0TCb ( login: admin / 123456 ) .

Please let me know if that's ok or you need any extra info. Thanks!! 🙏

hello, I was having the same problem and I managed to solve it using the wordpress medatada query. It even took down my whole website.

The easiest solution was to change the ACF query $item = get_post_meta(get_the_ID(), 'Your_Term', true);

And this way the error was mitigated. I hope to help you

I have also encountered a similar issue:
When Elementor loads dynamic labels from ACF, if the ACF dynamic labels are arrays, the stricter formatting requirements in the PHP 8 environment may lead to errors due to incorrect type definitions. However, this issue can be resolved by downgrading PHP to version 7.4.
I have set up a complete testing environment that can replicate this issue. If needed, I can provide it to the Elementor team.

I've also run into this issue. As @hogash has correctly identified, it's because ElementorPro\Modules\DynamicTags\ACF\Module->filter_post_in_preview is returning the wrong value when no action is taken by the filter. The method should return $null not $post_id.

@nicholaszein Please see my support case #TS2R8AQR2KK7 where I too have shared videos demonstrating the cause of this issue.

Thanks

Not sure if this is related, but also noticed that any ACF Option Fields return NULL when previewing a Draft (Post, Page). This is only an issue with Elementor Pro 3.25 and above. Disabled Elementor Pro and everything works. Ended up reverting to 3.24. to resolved.

I want to share my story and experience related to this issue in Elementor Pro. Perhaps my experience will be useful for other users and developers.

Problem Description

After updating WordPress to version 6.7.1 and several plugins, including Elementor and Elementor Pro, I encountered two main problems:

1. Preview mode does not work not only in Elementor but also in the standard WordPress editor. When clicking on "Preview," a fatal error occurs.
2. The get_field function from ACF always returns null in preview mode, despite having data available and valid on the frontend.

Error Logs

When attempting to preview the standard WordPress editor, the following error appears in the debug log:

[18-Dec-2024 11:13:53 UTC] Fatal Error: Uncaught TypeError: in_array(): Argument #2 ($haystack) must be of type array, null given in ../wp-content/themes/theme-name/functions.php:93
Stack trace:
#0 ../wp-content/themes/theme-name/functions.php(93): in_array(373807373, NULL)
#1 ../wp-includes/class-wp-hook.php(324): msq_employment_notice_navigation('')
#2 ../wp-includes/plugin.php(205): WP_Hook->apply_filters('', Array)
#3 ../wp-content/themes/theme-name/template-parts/header/masthead.php(5): apply_filters('msq_navigation', '')
#4 ../wp-includes/template.php(812): require('..')
#5 ../wp-includes/template.php(745): load_template('..', false, Array)
#6 ../wp-includes/general-template.php(206): locate_template(Array, true, false, Array)
#7 ../wp-content/themes/theme-name/header.php(36): get_template_part('template-parts/...')
#8 ../wp-includes/template.php(810): require_once('/var/www/html/h...')
#9 ../wp-includes/template.php(745): load_template('/var/www/html/h...', true, Array)
#10 ../wp-includes/general-template.php(48): locate_template(Array, true, true, Array)
#11 ../wp-content/themes/theme-name/single-webinare.php(94): get_header()
#12 ../wp-content/themes/theme-name/single-webinare.php(3): include('..')
#13 ../wp-includes/template-loader.php(106): include('..')
#14 ../wp-blog-header.php(19): require_once('..')
#15 ../index.php(17): require('/var/www/html/h...')
#16 {main}
  thrown in ../wp-content/themes/theme-name/functions.php on line 93 URL: https://site.domain.com/?post_type=webinare&p=373807373&preview=true

Analysis and Debugging

1. Preview mode and ACF get_field: In preview mode, any call to get_field (even get_field('option')) returns null, although the data is available and valid on the frontend.
2. Reverting Changes: It was obvious that the problem "appeared" only after updating the system, so I reverted all updates to the previous stable version for further debugging and problem identification.
3. Sequential Updates: I began updating the system step by step (WordPress and other plugins), each time trying to open the page in preview mode to find the source of the problem.
   3.1 It was clear to me that the problem should lie either in WordPress or ACF PRO, but as it turned out, the issue was exclusively with Elementor PRO.
4. Confirming Suspicions Related to Elementor PRO: After updating to the current latest version, the problem reappeared. However, if I deactivated the Elementor Pro plugin (thanks to the hint from @blockmonkey), the problem disappeared, and the preview worked without issues.
5. Debugging with VS Code:

   • I used the debugger in VS Code to track where the option page data was not reaching my filter function.

   • I entered the get_field function of ACF (file /wp-content/plugins/advanced-custom-fields-pro/includes/api/api-template.php).

   • I saw that my passed values (option) were received.

   • Line 20: I became curious why, specifically on line 20, the $post_id variable was overwriting itself (being modified), since line 20 is:

     $post_id = acf_get_valid_post_id( $post_id );

   • I opened the acf_get_valid_post_id function (file /wp-content/plugins/advanced-custom-fields-pro/includes/api/api-helpers.php).

   • After continuing debugging, the debugger simply returned to the ACF plugin's get_field function without returning anything.

   • I deactivated the Elementor Pro plugin and decided to repeat the test.

   • I set a breakpoint in my filter function.

   • I entered the get_field function of ACF (file /wp-content/plugins/advanced-custom-fields-pro/includes/api/api-template.php).

   • Then I entered the acf_get_valid_post_id function (file /wp-content/plugins/advanced-custom-fields-pro/includes/api/api-helpers.php).

   • I clicked "continue" in the debugger and saw that the debugger continued "working" in this function (acf_get_valid_post_id).

   • Then I reactivated Elementor Pro and repeated the same actions.

   • I realized that the debugger stops working in the acf_get_valid_post_id function (file /wp-content/plugins/advanced-custom-fields-pro/includes/api/api-helpers.php) at the condition check:

     $preload = apply_filters( 'acf/pre_load_post_id', null, $post_id );
     if ( $preload !== null ) {
         return $preload;
     }

     Lines 2162-2165

   • I added a local variable isset( $wp_filter['acf/pre_load_post_id']) in the debugger.

   • The debugger indicated that this variable had the value of my post that I wanted to view in preview mode.

   • I deactivated Elementor Pro again, ran the test once more, and found that this variable always equals null.

   • And exactly the acf_get_valid_post_id function (file /wp-content/plugins/advanced-custom-fields-pro/includes/api/api-helpers.php):

     $preload = apply_filters( 'acf/pre_load_post_id', null, $post_id );
     if ( $preload !== null ) {
         return $preload;
     }

     checks if $preload = apply_filters( 'acf/pre_load_post_id', null, $post_id ); equals null — if so, it continues working in the function; if not, it returns.

   • Since I was almost 100% sure that the issue was with Elementor Pro, I decided to search the files for this filter (acf/pre_load_post_id).

   • I found it in the file /wp-content/plugins/elementor-pro/modules/dynamic-tags/acf/module.php on line 27.

   • Therefore, because Elementor Pro adds this filter prematurely, the ACF logic does not work correctly.

   • I agree with @edwardkay that this filter should return null, not the current post_id.

Solution

I commented out the addition of the filter in the Elementor Pro file:

// /wp-content/plugins/elementor-pro/modules/dynamic-tags/acf/module.php on line 27
// add_filter( 'acf/pre_load_post_id', [ $this, 'filter_post_in_preview' ], 10, 2 );

After this, the site began to work correctly, and the preview mode functioned as expected.

Site Structure

I use a custom post type. For it, a separate file header-second.php is connected, which contains a function that uses apply_filters. This function checks whether the current page is in the ACF option page array and returns true or false. However, due to the aforementioned conflict, the array was being passed as null.

Conclusion

The issue arose because Elementor Pro adds the acf/pre_load_post_id filter and returns incorrect data, which disrupts the operation of ACF.

I hope my experience helps in resolving this issue in future updates.
P.S
if there is a need - I can add to this comment screenshots and a screen record

P.S.S. I apologize for such a long comment. This is my first comment :)

Not sure if this is related, but also noticed that any ACF Option Fields return NULL when previewing a Draft (Post, Page). This is only an issue with Elementor Pro 3.25 and above. Disabled Elementor Pro and everything works. Ended up reverting to 3.24. to resolved.

You are right, when I publish template (via Wordpress edit) I can edit it with Elementor and there is no error. Creating new one is impossible without seeing error, but it is creating drafts.

Hello, Good day.

May I ask if this issue has been resolved on the recent patches? I am getting this error today too.

I had to change my PHP version to 7.4 and change the Elementor version to 3.24.4 to fix the preview issue. However, it doesn't display the dynamic values of the templates.

Uncaught Error: Object of class WP_Term could not be converted to string in ../advanced-custom-fields-pro/includes/acf-value-functions.php:96
Stack trace:
#0 ../advanced-custom-fields-pro/includes/api/api-template.php(246): acf_get_value(Object(WP_Term), Array)
#1 public_html/staging/wp-content/plugins/elementor-pro/modules/dynamic-tags/acf/dynamic-value-provider.php(48): get_field_object('field_676a0a819...', Object(WP_Term))
#2 ../elementor-pro/modules/dynamic-tags/acf/dynamic-value-provider.php(60): ElementorPro\Modules\DynamicTags\ACF\Dynamic_Value_Provider->get_field_object('field_676a0a819...', Object(WP_Term))
#3 ../elementor-pro/modul in ../advanced-custom-fields-pro/includes/acf-value-functions.php on line 96

Thank you,

It is not solved yet, We have the same problem with Elementor PRO version 3.26.3. Just updated yesterday (22025 jan 12th).

Same issue here. Thanks @rekki13 for the quick fix.

Same issue here as well,

When upgrading to Elementor Pro 3.25 and above, I receive Fatal Errors resulting in a broken page/layout when viewing preview mode as others have experienced.

Uncaught Error: Object of class WP_Term could not be converted to string in /advanced-custom-fields-pro/includes/acf-value-functions.php:96

Fatal error: Uncaught TypeError: Illegal offset type in isset or empty in /advanced-custom-fields-pro/includes/local-meta.php:197

I rolled back to Elementor Pro 3.24 which fixes the issue, however deferring any upgrades long term isn't ideal.

I went ahead & applied @rekki13 solution, the fix works with Elementor Pro 3.25 and above.

I hope the awesome folks at Elementor can come up with a stable solution for this bug to eliminate having to defer version upgrades for Elementor Pro.

Hi everyone!

It's been a while... Apologies for the delay.

Thank you @hogash, @edwardkay, @blockmonkey, and @rekki13! Your feedback helped us identify and safely reproduce this issue! 🙏

We are working on a solution for this issue, and I will update you as soon as I have more information.

Meanwhile, a workaround for this issue is to Publish your documents before trying to edit with Elementor. We understand this may not be the desired solution in some cases, but it helps prevent this issue from happening.

Until next time!

Nick

Hey everyone!

We have great news! 🙌

📢 We're happy to announce that the issue you raised was resolved in Elementor v3.28.0! 🥳

✅ Feel free to check it out and update your plugin to the new version!

Check the changelog for more information:
Changelog of Elementor and Elementor Pro

Cheers 🥂