Views plugin lets you build your own custom search for any content type. These searches can be based on post content, taxonomies and custom fields.
When you ask for help or report issues, make sure to tell us settings for your custom search.
The customer was unable to get Relevanssi to recognize their custom post types ("fires") on their site, resulting in zero search results, despite it working with other content areas.
Solution:
We identified that the issue stemmed from the theme filtering the post types available in the default search widget, restricting results to only pages and posts. We adjusted the settings under Appearances > Theme Settings > Layout Settings > Search Content to exclude the filtering, allowing all custom post types to be displayed. After this adjustment, search results were successfully returned.
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 reported two issues with their search function on the page: (1) when clicking the "apply" button, the view jumps back to the beginning of the website instead of staying at the current position; (2) the search function only searches by post title, but they want it to search all content, including cities in a specific column.
Solution:
We checked the page and confirmed that the issue with the search redirecting to the home page was not reproducible, suggesting it may have been resolved. For the search to include text from custom fields (such as cities), we recommended using the "Relevanssi" plugin. The customer integrated Relevanssi, configured it, and confirmed that the search functionality now works as intended.
The customer encountered an accessibility error "Missing form label" when running an accessibility check using WAVE on a search filter created with Toolset Views. The issue was due to the text search input field missing an id attribute, which caused the WAVE tool to flag the error. The customer attempted to add a label with the for attribute but still encountered the issue.
Solution:
We initially suggested including both the label and the wpv-filter-search-box shortcode within the
The customer wants to insert a search form created with Toolset into the homepage of their site built with Divi. They have followed documentation for Gutenberg, but it is not applicable for Divi without losing their work. Additionally, they want to display search results in multiple columns instead of a single large column.
Solution:
To insert the search form into the Divi homepage, use the "wpv-view" shortcode:
[wpv-form-view name="View 1" target_id="123"]
Replace '123' with the ID of the page where search results should appear. Use the following shortcode on the results page:
[wpv-view name="View 1" view_display="layout"]
In the Divi editor, use a text or shortcode widget to place these shortcodes.
Problem:
The customer reported that updating filter values triggers the fade effect, but the posts remain unchanged. This issue occurs on their articles and ebooks pages. Solution:
To troubleshoot, we requested temporary admin login details and permission to create a staging version of the site for debugging. After initial investigations and involving our 2nd tier support, we created a new view for the Articles post type with an Ajax-enabled category filter. This view worked as expected without the customizations. We replicated this setup on the production site, creating an alternative view (Alt Articles) and recommended that the customer gradually apply their customizations to identify the step causing the issue.
