I'm trying to fetch one custom post with two values: the logged in user ID and a known string, both as variables.

The query works out fine when testing on an admin account where the user ID is 1 and shows the correct custom post with my query. However, when I test the same query logged in on a regular user where user ID is 4, the query gives no results.

When I insert the hardcoded data in place of either of the variables in the query, it does show the correct result, despite being the exact same values and types when var_dump()ing them and regardless of account.

My code for the query goes as follows:

$inner_args = array(
    'post_type' => 'any',
    'post_status' => 'any',
    'posts_per_page' => -1,
    'meta_query'    => array(
        'relation'      => 'AND',
            'key'       => 'track_url',
            'value'     => $track_url,
            'compare'   => '=',
            'key'       => 'review_user_id',
            'value'     => $current_user_id,
            'compare'   => '=',
$my_query = null; /// for safety
//wp_reset_postdata(); /// changed nothing
//wp_reset_query(); /// also changed nothing
$my_query = new WP_Query($inner_args);

After the query I try display data from it with a standard while loop:

if( $my_query->have_posts() ) {
    while ($my_query->have_posts()) {

         * Do things with the queried post


When checking the SQL request with echo $my_query->request;, where one uses variables and the other hardcoded data, both outputs are identical. I've tested this on the admin account and regular user account. Again, former works with variables, the latter doesn't.

I figured something might be off when querying through WP_Query, so I attempted the same with a handwritten query (effectively copy-pasting the result of echo $my_query->request; and adding my two variables). Its result is identical to the WP_Query result, which is no results for the regular user.

$my_query = $wpdb->get_results($wpdb->prepare ( "
                  SELECT lju_posts.* FROM lju_posts INNER JOIN lju_postmeta 
                  ON ( lju_posts.ID = lju_postmeta.post_id ) INNER JOIN lju_postmeta 
                  AS mt1 ON ( lju_posts.ID = mt1.post_id ) WHERE 1=1 
                  AND ( ( lju_postmeta.meta_key = 'track_url' AND lju_postmeta.meta_value = %s ) 
                  AND ( mt1.meta_key = 'review_user_id' AND mt1.meta_value = %s ) ) 
                  AND lju_posts.post_type IN ('post', 'page', 'attachment', 'e-landing-page', 
                  'product', track', 'review') AND ((lju_posts.post_status <> 'trash' AND 
                  lju_posts.post_status <> 'auto-draft')) GROUP BY lju_posts.ID 
                  ORDER BY lju_posts.post_date DESC", 
                  $track_url, $current_user_id ));

I am querying on ACF fields, but I'm not convinced it's an ACF problem when it works perfectly fine when tested with an admin account and with variables, but doesn't work when tested with a regular user account.

I've tried:

  • Changing user roles for user account
  • Creating a fresh user account and running through the process again
  • Adding 'NUMERIC' to field type in meta arguments
  • Manually creating the custom post through the wp-admin interface
  • Using a hardcoded string for $current_user_id

I can't wrap my head around why the query fails to show the custom posts when they exist, and with the correct fields as well. Why do variables seemingly break the query behaviour for one user but not for another? If anyone has some insight into this phenomenon, I'd greatly appreciate it and hopefully be able to move on.

  • I might be helpful to print out the WP_Query->request and running the SQL directly to narrow down specifically where it's running into issues.
    – Howdy_McGee
    Sep 23 at 21:54
  • @Howdy_McGee I already checked the output for WP_Query->request, but just to be sure I logged and compared both outputs again, with and without variables for the logged in user's perspective. Once again, both SQL outputs were identical, but the variant in which variables were used gave no results. 2 days ago


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy