The customer experienced an issue where a Kadence accordion, used within a Toolset View block with AJAX filters, stopped functioning correctly after filtering. The accordion worked fine on the initial page load but failed to open after AJAX filtering, suggesting that the AJAX process was breaking the accordion functionality.
Solution:
The problem was caused by the Kadence Accordion's JavaScript not being reinitialized after the AJAX content load. The supporter added custom JavaScript to the View settings to reinitialize the accordion each time the AJAX filter results were updated. The JavaScript snippet used was:
The customer had a search view that was supposed to show both custom post types (CPTs) "listings" and standard posts, based on the fields "city" and "listing category." However, when users were redirected to the search from their account, only "listings" were shown, and standard posts were not included in the results, even though they should have been.
Solution:
The issue was due to a discrepancy between the "listing category," which was set as a taxonomy for the "listings" CPT, and a custom field ('wpv-listing_category') for standard posts. The provided code was only testing for taxonomies and not for the custom field, causing standard posts to be excluded from the results. We modified the code to check both the taxonomy and custom field values, ensuring that both "listings" and standard posts would be displayed based on the search criteria.
The customer wants to display posts on a page filtered by the taxonomy "Mitglieder" and allow users to filter the list by the terms of this taxonomy. However, setting the search filters resulted in the page querying all posts when no filters were applied by the user, rather than pre-filtering by the "Mitglieder" taxonomy.
Solution:
We added a custom code snippet to the site's functions.php file using the wpv_filter_query filter. This code pre-filters the query to include only posts that have any term from the "Mitglieder" taxonomy assigned. This initial filtering ensures that the user can use the front-end filter without losing the pre-filtered query. The code targets only the specific view in question, ensuring that posts without any terms assigned from the "Mitglieder" taxonomy are excluded from the results:
add_filter( 'wpv_filter_query', 'filter_mitglieder_taxonomy', 101, 3 );
function filter_mitglieder_taxonomy($query, $setting, $views_ID)
{
if($views_ID == 1082) // your view ID
{
$query['tax_query'][] = array(
'taxonomy' => 'mitglieder', // taxonomy name
'field' => 'slug',
'operator' => 'EXISTS' // Check if any term from the taxonomy is assigned
);
$query['tax_query']['relation'] = 'AND';
}
return $query;
}
The customer has several events, each with multiple dates stored in a repeating field group. They want to display all events in a list ordered by the date of the first event. The inner view correctly retrieves the next upcoming date of each event, but they want the outer view to use the same logic to order the events by the first upcoming date.
Solution:
We explained that due to the way repeatable field groups are implemented (as child posts), the fields for the event dates belong to the child posts, making it impossible to directly order the outer events by these fields. The suggested solution is to add a field directly to the event posts that records the next upcoming event date. This field can then be used to order the event posts. To automate this process, the customer can use the save_post hook to copy the upcoming date to the main post whenever changes are made, ensuring that the data stays up to date.
After updating Toolset Blocks from version 1.6.14 to 1.6.15, the post date filtration functionality in multiple views on my site stopped working. The view loop output no longer displays any items in the updated environment, while it works correctly on the production environment with the older version.
Solution:
In the new version of Toolset Blocks, it is necessary to specify a value for the attribute in the date filter section of the view's shortcode. If no value is specified, the filter conditions are combined with an AND operation, resulting in no items being displayed. Removing the "meetingmonth" attribute or specifying a value for it in the shortcode resolves the issue.
I have a map and a search query on a page where the distance is hard-coded to 50 miles. If no results are found within 50 miles, I want to automatically expand the search to 350 miles without requiring the user to re-enter their address. I considered using the [wpv-no-items-found] section to trigger a second view but wasn't sure how to pass the user's address to the second view.
Solution:
You can pass the URL parameter containing the user's address from the first view to the second view. Use the URL parameter toolset_maps_distance_center to set the address in the second view, which will then perform the expanded search within 350 miles.
