BUG: ACF Post Object Field - Looper Provider & Provider Output Conditions

Hello, I am experiencing multiple problems with the ACF integration, specifically with the Object Field. I am unable to conditions for the output of my looper provider which is based on an ACF Post Object field, and the ACF integration seems to be getting stuck in a loop and breaking the frontend of the website (see end of post for PHP notices and stack trace).

First let me outline the situation… the ACF Post Object field is configured like this:

  • Filter by Post Type: “work”
  • Allow Null - TRUE
  • Select multiple values - TRUE
  • Return Format: Post Object
  • This field is assigned to “Work” post type edit pages in the WP Admin

I am attempting to use this field output in my Cornerstone Single Layout template for the Work post type to display a list of related projects. But I only want the Related Projects section to display if there are Work posts that have been assigned using the above Post Object field. If no Work posts have been chosen, then the “Related Projects” section should not display, and a “Featured Work” section should display instead.

Here is my “Work - Single” layout in Cornerstone:

I have a Related Projects Section which is the looper provider, and then the Related Projects and Featured Work rows are nested.

The looper provider for the Section is based on the following Dynamic Content:
{{dc:acf:post_field field="related_projects_array"}}

The Related Projects row has the following condition set:

And the Featured Work row has the following condition set:

The problem is that these conditions do not work as expected. When the Post Object ACF field is empty (no posts have been selected) the corresponding looper provider does not resolve as “empty”.

I have also tried using the String and Number expressions as my conditions, but the field does not evaluate as 0 or an empty string using {{dc:acf:post_field field="related_projects_array"}}. So I’m not sure how to properly setup this condition, and this is crucial to the layout properly displaying.

A workaround is to create a checkbox (true/false) field, which toggles the display of the related_projects_array Post Object field, and then using a number expression as the condition.

The above workaround works for setting element conditions, but my major concern is that the Post Object field seems to be causing problems on the backend. When developing this particular layout (the Single - Work layout) and viewing the pages on the frontend, my pages started timing out and failing to load multiple times since adding the Post Object looper provider. This usually happens when the Post Object field is empty on a given Work post (single post view).

Also, when the Post Object field is empty, the looper provider outputs the current post. I’m sure this is related to the issue somehow.

Here is the notice and stack trace from debug.log:

PHP Notice:  Undefined index: return_format in /Users/colinsafranek/Local Sites/pinnacle-dev/app/public/wp-content/themes/pro/cornerstone/includes/integration/acf.php on line 247
PHP Stack trace:
PHP   1. {main}() /Users/colinsafranek/Local Sites/pinnacle-dev/app/public/index.php:0
PHP   2. require() /Users/colinsafranek/Local Sites/pinnacle-dev/app/public/index.php:17
PHP   3. wp() /Users/colinsafranek/Local Sites/pinnacle-dev/app/public/wp-blog-header.php:16
PHP   4. WP->main() /Users/colinsafranek/Local Sites/pinnacle-dev/app/public/wp-includes/functions.php:1291
PHP   5. WP->parse_request() /Users/colinsafranek/Local Sites/pinnacle-dev/app/public/wp-includes/class-wp.php:750
PHP   6. do_action_ref_array() /Users/colinsafranek/Local Sites/pinnacle-dev/app/public/wp-includes/class-wp.php:388
PHP   7. WP_Hook->do_action() /Users/colinsafranek/Local Sites/pinnacle-dev/app/public/wp-includes/plugin.php:518
PHP   8. WP_Hook->apply_filters() /Users/colinsafranek/Local Sites/pinnacle-dev/app/public/wp-includes/class-wp-hook.php:327
PHP   9. rest_api_loaded() /Users/colinsafranek/Local Sites/pinnacle-dev/app/public/wp-includes/class-wp-hook.php:303
PHP  10. WP_REST_Server->serve_request() /Users/colinsafranek/Local Sites/pinnacle-dev/app/public/wp-includes/rest-api.php:370
PHP  11. WP_REST_Server->dispatch() /Users/colinsafranek/Local Sites/pinnacle-dev/app/public/wp-includes/rest-api/class-wp-rest-server.php:414
PHP  12. WP_REST_Server->respond_to_request() /Users/colinsafranek/Local Sites/pinnacle-dev/app/public/wp-includes/rest-api/class-wp-rest-server.php:987
PHP  13. Cornerstone_Routing->data() /Users/colinsafranek/Local Sites/pinnacle-dev/app/public/wp-includes/rest-api/class-wp-rest-server.php:1140
PHP  14. apply_filters() /Users/colinsafranek/Local Sites/pinnacle-dev/app/public/wp-content/themes/pro/cornerstone/includes/classes/common/class-routing.php:72
PHP  15. WP_Hook->apply_filters() /Users/colinsafranek/Local Sites/pinnacle-dev/app/public/wp-includes/plugin.php:189
PHP  16. Cornerstone_Routing->{closure:/Users/colinsafranek/Local Sites/pinnacle-dev/app/public/wp-content/themes/pro/cornerstone/includes/classes/common/class-routing.php:120-122}() /Users/colinsafranek/Local Sites/pinnacle-dev/app/public/wp-includes/class-wp-hook.php:303
PHP  17. Cornerstone_Choices_Controller->get_dynamic_options() /Users/colinsafranek/Local Sites/pinnacle-dev/app/public/wp-content/themes/pro/cornerstone/includes/classes/common/class-routing.php:121
PHP  18. apply_filters() /Users/colinsafranek/Local Sites/pinnacle-dev/app/public/wp-content/themes/pro/cornerstone/includes/classes/controllers/class-choices-controller.php:36
PHP  19. WP_Hook->apply_filters() /Users/colinsafranek/Local Sites/pinnacle-dev/app/public/wp-includes/plugin.php:189
PHP  20. Cornerstone_Dynamic_Content_ACF->populate_option_fields() /Users/colinsafranek/Local Sites/pinnacle-dev/app/public/wp-includes/class-wp-hook.php:303
PHP  21. Cornerstone_Dynamic_Content_ACF->get_normalized_field_options() /Users/colinsafranek/Local Sites/pinnacle-dev/app/public/wp-content/themes/pro/cornerstone/includes/integration/acf.php:294

That notice is repeated about a thousand times in my debug.log file.

I also see this notice repeated:

PHP Notice:  Trying to get property 'ID' of non-object in /Users/colinsafranek/Local Sites/pinnacle-dev/app/public/wp-content/themes/pro/cornerstone/includes/integration/acf.php on line 189

I will share my secure login credentials below so this can be investigated. Thank you.

Hello @adaptifyDesigns,

Thanks for posting in!

It seems that you are using the incorrect condition. Take note that you have related_projects_check and related_projects_array ACF Fields.

You can use the related_projects_check in your condition by having this {{dc:post:meta key="related_projects_check"}} == 1 for TRUE or {{dc:post:meta key="related_projects_check"}} == 0 for False instead.

Hope this makes sense.

Yes, thank you, I know that… did you read my post?

I’m sorry to be rude… and I know you must have hundreds of support tickets that you have to review, but it seems like you did not read my post thoroughly. I apologize if I’m making an assumption, but I think I’ve identified a serious issue with the Post Object field in Cornerstone, and I think it deserves some serious attention.

Did you see the php notices I shared? Did you read the part about the Post Object looper outputting the current post when empty? Did you read the part about this issue crashing my site? This is a serious problem.

I know that I can use the related_projects_check field to set the element conditions. I wrote that in my post, that I have used that as a workaround. But this does not solve the underlying issue, which is that the Post Object field is creating some major problems when used as a looper provider, and the “looper provider output” condition does not function as intended with this field either.

I would really appreciate it if you would re-read my post more carefully, and please take this seriously.

I’m spending the time to bring this bug to your attention in detail, as an active and paying member of the theme.co community. I would appreciate some reciprocation. Thank you.

Hello @adaptifyDesigns,

We apologize if we have only provided the alternative solution to your issue which is the “Provider Output is not Empty” and/or “Provider Output is Empty” that you use as your condition. This condition did not give you the correct output because the dynamic content may not support the “Post Object” field type.

If I may, you can have a structure something like this to prevent from always running the looper provider even if it has no related projects which may result to an infinite loop.

IF `related_projects_check` is true

    THEN we can run the ACF Looper Provider 

ELSEIF `related_projects_check` is false

   THEN we can display something else

ENDIF

With the above condition structure, the looper provider can only be run if there is a related projects assigned to the current custom post type. This should prevent from having an infinite loop or undefined return format.

Be advised that the ACF Dynamic Content may not support the Post Object field type. At the moment, these are the supported field types:

I will forward this thread to @Kory, one of our developers, to be able to give you more details about the Post Object field type.

Thank you for your understanding.

Thank you for forwarding this to @kory.

The Post Object field is also a multi-dimensional field, similar to the user select field covered in that docs article. Cornerstone handles it well, except for when it’s empty.

@kory feel free to check out my dev site, login info is in the secure note above. I can also send you a full copy of my local debug.log if you would like to review all the notices.

Thanks for looking into this.

Hey @adaptifyDesigns,

The WP login credentials don’t work so I tried to replicate your setup on my site and I don’t get any error when the Provider Output is empty though the condition doesn’t seem to work so I’ll post this in our issue tracker so this will be queued to be investigated by our development team.

Please keep your testing site up and give us the updated login info so our dev team could get in when it’s time to investigate.

Thanks.

Hey, thanks @christian, I received an email notification about that password being reset, so I’m thinking one of your team members did that.

I have reset the password and tested that it is working. Please see new credentials below.

Please also see this related ticket regarding a similar issue with the ACF repeater field.

Again, it’s possible to add an ACF true/false checkbox field preceding the multi-dimensional fields, and then use that field as the element condition in cornerstone. This works, but it is not ideal, because that means I will have to create the true/false field for every multidimensional field throughout my site. It is also not ideal because if there are already many posts/pages that have data entered into the multi-dimensional fields, adding a checkbox field means that someone has to go through all the effected posts/pages to either check the box (if the field was unchecked by default) in order for the multi-dimensional data to display, or they would have to uncheck the box (if the field was set to checked by default) to prevent a broken field output.

So it would be great if this fix was made a priority, as it really makes it quite inconvenient to use the ACF integration.

Your help is much appreciated.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.