Post Object field: "no matches found"

• mtm

• December 10, 2016 at 2:56 am

Suddenly my Post Object fields are returning no matches in their dropdrown menus (see screenshot).

This was not an issue until recently, and no existing links on older posts have been severed. I have disabled plugins one by one to find a conflict with no luck and have seen this working in the theme I have written already – the posts in question are all Custom Post Types declared in the theme so switching out to a default theme does not give me the option to test the issue, although no changes have been made to this since long before it stopped working.

Does anyone know what could cause this? The site recently moved to a new server with a different hosting provider. Is there any way settings at the server end could affect this?

Screen-Shot-....png

• John Huebner

• December 10, 2016 at 7:39 am

I cannot say for sure what could be causing this, but I can guess. One reason, the first that comes to mind, is that maybe the post type is not defined when ACF is running the query to find posts. When are you defining the custom post types in the theme? On what WP hook?

• mtm

• December 11, 2016 at 12:21 am

thanks john (i should just keep you on retainer here).

i’m using the following code in the theme’s functions.php file:

// Add Multiple Custom Post Types

add_action('init', 'all_custom_post_types');

function all_custom_post_types() {
  $types = array(
    // News
    array('the_type' => 'news',
          'single' => 'News',
          'plural' => 'News'),
    // Artists
    array('the_type' => 'artist',
          'single' => 'Artist',
          'plural' => 'Artists'),
    // Releases
    array('the_type' => 'release',
          'single' => 'Release',
          'plural' => 'Releases')
  );

foreach ($types as $type) {
  $the_type = $type['the_type'];
    $single = $type['single'];
    $plural = $type['plural'];
  $labels = array(
      'name' => _x($plural, 'post type general name'),
      'singular_name' => _x($single, 'post type singular name'),
      'add_new' => _x('Add New', $single),
      'add_new_item' => __('Add New '. $single),
      'edit_item' => __('Edit '.$single),
      'new_item' => __('New '.$single),
      'view_item' => __('View '.$single),
      'search_items' => __('Search '.$plural),
      'not_found' =>  __('No '.$plural.' found'),
      'not_found_in_trash' => __('No '.$plural.' found in Trash'),
      'parent_item_colon' => ''
    );
    $args = array(
      'labels' => $labels,
      'public' => true,
      'publicly_queryable' => true,
      'show_ui' => true,
      'query_var' => true,
      'rewrite' => true,
      'capability_type' => 'post',
      'hierarchical' => false,
      'has_archive' => true,
      'menu_position' => 5,
      'supports' => array('title','editor','thumbnail'),
      'show_in_menu' => true,
      'show_in_nav_menus' => true,
      'taxonomies' => array( 'category' )
    );

    register_post_type($the_type, $args);
  }
}

is this what you mean?

• John Huebner

• December 11, 2016 at 2:48 am

Yep, that’s what I meant, but the post type should be defined when ACF is running the query, so that’s not the problem. At this point I’m not sure where to tell you to look. There are a few things you can check.

1) There is an error during the AJAX requests. Turn on WP debug and WP log and see if any php error happen during the query. This could happen when changing servers if the php version is different.

2) There is a pre_get_posts filter that interfering with the query. Unlikely if the code is the same on both servers, but you never know. You can try disabling any filters that you find.

3) There is and acf/fields/post_object/query filter https://www.advancedcustomfields.com/resources/acf-fields-post_object-query/ that’s interfering, again, unlikely if the code on both servers is the same. try disabling the filters.

• mtm

• December 11, 2016 at 10:22 pm

thanks john,

so, i haven’t found any pre_get_posts filters to disable, and i’m not sure what you mean by point 3) above, which suggests to me that i didn’t add anything of that type to the theme either. where/how would i check this?

i enabled debug mode and the error log but haven’t seen anything. there were one or two things that came up on the front end which i was able to fix but they were unrelated to this. i’m not seeing anything in the back end where the list is returning empty.

i may not have used the log properly, as it didn’t create a file.

i’ve gone back to the dev site which is still up and have found tough that i have the same problem there, so it must be related to something i did just before completing this job and taking it live. do you have any idea where else i could look for the cause please?

thanks.

• John Huebner

• December 12, 2016 at 1:00 am

WP will only start creating the log file when there are errors.

What happens if you edit the post object field and remove any post type or taxonomy filters? Are any results shown in the select box?

• mtm

• December 12, 2016 at 4:35 am

i thought of this too and checked but it doesn’t change anything. i’ve just double checked on the dev version on my own server too but it’s the same there.

• John Huebner

• December 15, 2016 at 6:53 am

I’ve tried, but I cannot recreate the problem that you’re seeing.

Is this related to a specific type of user/role? Could it be something related to the permissions of the post type?

• mtm

• December 16, 2016 at 1:18 am

thanks john,

i don’t think it is – i’m seeing the same thing in both admin and editor accounts. how would i check the permissions on the post type? to my knowledge i haven’;t set any restrictions.

• mtm

• December 16, 2016 at 10:07 pm

i found it. the problem was simply that it wasn’t enough to leave the taxonomy filter blank for a catch-all of posts when setting up the post object field – as well as specifying post types, it turns out one must also specify at least one taxonomy in the box below that one.

it’s working fine now, and i must admit i do feel something of a plum.

thanks john, as ever, for your help with this.