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 created a view with two query filters: (1) the page must be a subpage of the page on which the view resides, and (2) the custom field "Card Exclude" must not have the value "1." Despite having four subpages, with only one marked as excluded, the view displayed no pages. Additionally, the unchecked state of the checkbox field was not saving a value to the database.
Solution:
The issue stemmed from how checkbox field values were stored in the database. If the checkbox was never saved, it remained absent in the database. If checked and then unchecked, it stored a value of 0, while being checked saved a value of 1. The workaround applied involved manually saving the field as true (1) and then unchecking it to store false (0), allowing the query filter to function correctly. Additionally, two other solutions were suggested:
1- Using a conditional statement in the Loop Editor: [wpv-conditional if="( $(wpcf-exclude-card) ne '1' )"].
2- Custom code in the query to handle cases where the field might be NULL or 0.
The customer wanted to filter a view on their website so that only specific URL parameters, such as "category=blog," remain visible in the URL after filtering. By default, all parameters were displayed, which cluttered the URL with unnecessary information.
Solution:
A combination of PHP and JavaScript was used to selectively retain only the category parameter in the URL after filtering. Here’s the implemented approach:
1- A hidden field was added to capture and maintain the category parameter, using a custom function in the theme’s functions.php file:
add_filter('wpv_filter_end_filter_form', 'add_hidden_category_param', 99, 4);
function add_hidden_category_param($out, $view_settings, $view_id, $is_required) {
$views = array(12345); // Replace with the View ID
if (in_array($view_id, $views) && $is_required) {
$category = isset($_GET['category']) ? $_GET['category'] : '';
$out = '<input type="hidden" id="category" name="category" value="' . esc_attr($category) . '" />' . $out;
}
return $out;
}
This function captures the category parameter and stores it in a hidden input field to ensure it persists through the filter updates.
2- In the View's Custom JavaScript section, this code was added to ensure only the category parameter remains visible in the URL
jQuery(document).ready(function($) {
$(document).on('js_event_wpv_parametric_search_form_updated', function(event, data) {
var url = new URL(window.location);
var category = url.searchParams.get("category");
jQuery('#category').val(category); // Update hidden input field with the category parameter
// Update the URL to show only the category parameter
let params = new URLSearchParams({ category: category });
window.history.replaceState({}, '', `${url.pathname}?${params.toString()}`);
});
});
This JavaScript ensures the URL updates to include only the category parameter after filtering, creating a cleaner URL.
The customer wanted to create a search form with drop-down options for filtering academic texts on their website, aiming to replicate a search functionality similar to that on the Jeb Dunnuck site. They faced difficulties implementing this using Toolset Views with the legacy editor.
Solution:
To achieve the desired search functionality, the customer was advised to add a select dropdown for post type filters within their view and use the following code for implementation:
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.
