Looper Not Displaying All Relevant Posts

Hi there,

For some reason a looper only seems to be outputting content from certain custom posts but skipping others that should be meeting the looper’s selection criteria.

In trying to troubleshoot it, it looks like even when I duplicate a post that is successfully being displayed, the duplicate, which has all the exact same info, doesn’t display.

All the software/plugins on the website are up to date and cache etc. is cleared.

Any help much appreciated!

Hello @detailsguy,

Thanks for writing in! What Looper Provider are you using? Is it the the Query String? Please include your query string in your response so that we can help you figure out to resolve the issue. We would also love to check your Looper Settings if you can provide us access to the site. You can create a secure note in your next reply with the following info:
– Link to your site
– WP login URL
– WP username
– WP password
– WP Administrator Role
- Confirmation that we can access and make changes to your site

To know how to create a secure note, please check this out: How The Forum Works

Best Regards.

Okay great, there are actually two Looper Providers, both of which are query strings with the provider item count set to “All”. They are meant to generate a current/future events list and a past events list.

In this case the post type “events” is a custom post and the “start_date” meta key is generated by an ACF field assigned to those custom posts.

1. Current + Future Events Looper Query String - post_type=events&orderby=meta_value&meta_key=start_date&order=asc .

There are the following display conditions applied to this looper/consumer to ensure it only displays posts on or after the current date:

  • {{dc:acf:post_field field=“start_date”}} after {{dc:global:date}}
    OR
  • {{dc:acf:post_field field=“start_date” }} is {{dc:global:date}}

2. Past Events Looper Query String - post_type=events&orderby=meta_value&meta_key=start_date&order=dsc

With the following condition:

  • {{dc:acf:post_field field=“start_date”}} before {{dc:global:date}}

Hello @detailsguy,

Since you are dealing with custom post types, meta keys and date value, you will need to use meta comparison in your query string. Please check out this thread instead as your reference:

Kindly let us know how it goes.

Great, so I removed the conditions and adjusted the first looper query to: post_type=events&meta_key=start_date&orderby=meta_value&order=ASC&meta_query%5B0%5D%5Bkey%5D=start_date&meta_query%5B0%5D%5Bvalue%5D={{dc:global:date format="Ymd"}}&meta_query%5B0%5D%5Bcompare%5D=%3E%3D

It seems to work, the only issue is that I need to exclude certain events that are private from the displayed events.

Before I was attempting to do this through conditions on the looper consumer that referred to an ACF check box, meaning a meta field with the key “private_event” and a value of either 1 or 0. The condition was set up using a string as follows:

  • {{dc:acf:post_field field=“private_event”}} is not 1

This doesn’t seem to work to hide those private events.

Can I solve this by updating the query string or could you provide another fix?

Hello @detailsguy,

You will also include the private_event meta in your query. Perhaps like this:

$meta_query[] = array(
                    array(
                        'key'     => 'start',
                        'value'   => date('Ymd'),
                        'compare' => '>=',
                    ),
                    array(
                        'key'     => 'private',
                        'value'   => 0,
                        'compare' => '=',
                    )
                );

Or you can use the Relation parameter something like this:

$meta_query[] = array(
                    'relation' => 'AND',
                    array(
                        'key'     => 'start',
                        'value'   => date('Ymd'),
                        'compare' => '>=',
                    ),
                    array(
                        'key'     => 'private',
                        'value'   => 0,
                        'compare' => '=',
                    )
                );

Be advised that the above is just an example and will not work out of the box. Please refer to the codex for more information.

Best Regards.

Great thanks! Removed conditions, updated the query, and looks good to go.

FWIW for the private events on or after current date setup I went with:

$meta_query[] = array(
                    array(
                        'key'     => 'start_date',
                        'value'   => date('Ymd'),
                        'compare' => '>=',
                    ),
                    array(
                        'key'     => 'private_event',
                        'value'   => 0,
                        'compare' => '=',
                    )
                );

$query = array(
    'post_type'  => 'events',
    'meta_key'   => 'start_date',
    'orderby'    => 'meta_value',
    'order'      => 'ASC',
    'meta_query' => $meta_query
);

Which output this monster query string:

post_type=events&meta_key=start_date&orderby=meta_value&order=ASC&meta_query%5B0%5D%5B0%5D%5Bkey%5D=start_date&meta_query%5B0%5D%5B0%5D%5Bvalue%5D={{dc:global:date format="Ymd"}}&meta_query%5B0%5D%5B0%5D%5Bcompare%5D=%3E%3D&meta_query%5B0%5D%5B1%5D%5Bkey%5D=private_event&meta_query%5B0%5D%5B1%5D%5Bvalue%5D=0&meta_query%5B0%5D%5B1%5D%5Bcompare%5D=%3D

Glad to hear that, @detailsguy

Do you have recommendations for max length for a query string?

Obviously it’s a useful tool to select and display specific data but I’m wondering at what point it would start to cause performance issues and slow page load times.

Hi @detailsguy,

There is no limit on the Query String length. It will affect the performance only when you are selecting a huge number of data using it, else it work perfectly fine.

Thanks

Great, thx for the info

Hey @detailsguy,

You’re welcome! if you have any other concerns or clarifications regarding our theme features, feel free to open up a new thread.

Thank you.

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