This short article provides details on Bricks’ bricks/posts/merge_query filter.
On pages rendered by an archive or search template, secondary queries like the ones used for showing recent posts or a nestable slider showing items from another CPT will not work properly out of the box.
This is because the default behavior is to merge the query arguments of this secondary or custom query with those from the main/default query for any given view.
Let’s say the view in question is a taxonomy term archive page – WooCommerce product category archive. For example, “Accessories” terms page showing all the products that belong to the Accessories product category. In a custom sidebar if you place a query loop that’s set to pull the latest 5 blog posts there will be no output since WordPress is looking for 5 blog posts that belong to the Accessories product category, a taxonomy that this post type is not even linked to and there are no matching items.
Solution
Add the following in child theme‘s functions.php (w/o the opening PHP tag) or a code snippets plugin:
add_filter( 'bricks/posts/merge_query', function( $merge, $element_id ) {
if ( $element_id === 'wghgco' ) {
return false;
}
return $merge;
}, 10, 2 );Replace wghgco with the Bricks ID of your Posts element or the element on which the query loop is turned on.
Examining the query
It is possible to see the query parameters that WordPress is actually using to render your loop.
add_filter( 'bricks/posts/query_vars', function( $query_vars, $settings, $element_id ) {
if ( $element_id === 'wghgco' ) {
print( '<pre>' . print_r( $query_vars, true ) . '</pre>' );
}
return $query_vars;
}, 10, 3 );shows, for example on the frontend:
where wghgco is the Bricks ID of query loop showing the 5 posts. As we can see, product_cat with the value of the current product category archive (from the default query), accessories in this example is being injected into the custom/secondary query.
After adding the bricks/posts/merge_query code, it will be fine:
