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.
