I’ve got a sidebar that depending on where you are on a site, returns records for a custom post type that have a tag whose slug matches the post’s slug. Up until a few days ago, this code worked perfectly, but it now cacks after the else : statement. It still works on my test environment, in fact. I’m wondering if there’s a more elegant/efficient way to do this:
<aside> <div id="whereSidebar"> <?php $selector = basename(get_permalink()); // get the current page's slug $pageTitle = get_the_title(); $args = array( 'post_type' => 'events', 'tag' => $selector, // drop in the current page's slug (I've set up tags with slugs that match those of post slugs so that I can pull related "Events" for specific "Places" or "Activities") 'meta_key' => 'start_date', 'orderby' => 'meta_value', 'order' => ASC, 'posts_per_page' => 4 ); $the_query = new WP_Query( $args ); if($the_query->have_posts() ) : while ( $the_query->have_posts() ) : $the_query->the_post(); ?> --- do stuff -- <?php endwhile; else : //query ALL posts from the EVENTS custom post type, not just those tagged to match the value in $selector $general = array( 'post_type' => 'events', 'meta_key' => 'start_date', 'orderby' => 'meta_value', 'order' => ASC, 'posts_per_page' => 4 ); $gen_query = new WP_Query( $general ); if($gen_query->have_posts() ) : while ( $gen_query->have_posts() ) : $gen_query->the_post(); ?> --- do basically the same stuff, but with a larger query result --- <?php endwhile; endif; wp_reset_postdata(); // closes events sub-query?> <?php endif // closes events main query ?> <?php wp_reset_postdata(); //reset the original page query ?> </div> <!--/.whereSidebar--> </aside>
I tried debugging but didn’t see anything that might be related. Haven’t delved into error logging.
On a whim, I just tried removing the ‘tag’ info from the first query (essentially making it the exact same as the 2nd query) and now the sidebar is not drawing records at all! Any idea why that would be?
My error log shows some deprecated stuff coming from the wp-includes/functions.php and other seemingly non-related things.
Is this your server error log or the debug.log in wp-content?
It’s called error.log and it’s a report I pulled from the server’s control panel. When I put the site into DEBUG mode, the errors match, however.
Can we see these errors? If the file is longer than about a dozen lines, please use a pastebin and post the pastebin url here.
This log is from yesterday, the errors to do with ASC have been repaired, as have the bloginfo(‘siteurl’) ones. The others seem to indicate wp-includes/functions.php as having some deprecated code present.
Upon further digging, it seems this problem is related to ‘posts_per_page’.
This sidebar is supposed to display posts in the ‘events’ custom post type whose tag slug matches the page title’s slug. If none match that criteria, go ahead and pull all events. There’s some other fun stuff in there too on the live site, like ordering them by event date, not showing them if they’re in the past… that kinda thing.
For some reason, though, adding ‘posts_per_page’ => 8 (or any number) to the sub-query produces no results despite empirical tests that events in fact do exist that match the query. The idea here is to limit the number of events shown to some number that the design likes, but that is informative to a visitor. 8 works in this case.
Removing ‘posts_per_page’ altogether seems to work – but imperfectly. I should now be defaulting to the number of posts specified in Settings/Reading (which I have set to 8). On the following page, only 6 events are being output, though I know for certain there are more events that should be displaying here (by looking at the Events listing):
Surely there’s something wonky here. Why would including ‘posts_per_page’ produce such unpredictable results? And why would the Settings/Reading setting not be governing the number of posts appearing?
Again – this seems to be working just fine in the test environment.
- The topic ‘Query by Tag first, if not present, return all from a post_type’ is closed to new replies.