Views is a WordPress plugin that lets you easily display content on your website's front-end in any way you choose.
Views User Guides include detailed documentation for creating lists of content, templates for content and archive page and also explain how to create parametric searches for any content type.
When you ask for help or report issues, make sure to tell us the versions of the Toolset plugins that you have installed and activated.
The customer reported a PHP error originating from views/invalidator.php on line 274. Additionally, they experienced issues with the Block Editor for CPTs and image uploading. Debugging revealed these issues could be related to cached views in Toolset and the latest WordPress update to version 6.7.
Solution:
1- Cached Views Issue:
Enabled the legacy Views interface following Toolset’s documentation on enabling legacy views. Cleared the cached views, which resolved the initial PHP error.
2- Image issue fix:
We released hotfixes for:
- Toolset Blocks 1.6.18
- Toolset Access 2.9.2
Advised the customer to update to these versions after creating a full backup.
The customer duplicated a site, and on the new version (SilverCoast), property images were missing. The image src attributes pointed to placeholders (data:image/gif;base64...) instead of actual image URLs. The backend displayed images correctly, but they did not show up on the frontend.
Solution:
We identified that the issue was related to custom code responsible for fetching media IDs using full media URLs. The original code checked the database for the full URL, including the domain, which failed after site duplication. We modified the code to extract the filename and match it in the database, ignoring the domain format. This allowed the media ID retrieval to work correctly across sites.
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 created a multilingual directory using Toolset to organize 'Contacts', 'Locals', and 'Employers' in a one-to-many relationship, with metadata categorizing roles. The English version of the directory page displayed correctly, but the French version showed a 'No items found' message, despite translated records and metadata.
Solution:
The issue was traced to a custom filter applied in the Toolset settings under Code Snippets. This filter used English terms (e.g., 'national-president') in the query, which prevented it from retrieving translated French records (e.g., 'président-e-national-e'). Disabling the snippet temporarily allowed French results to display. The snippet needs updating to include the French position names to ensure multilingual compatibility.
The customer was attempting to use a shortcode to display a custom field (CPF) conditionally within the Divi Theme Builder’s tab module. While the shortcode functioned correctly outside the Theme Builder, it only displayed the raw shortcode within the builder, failing to render the expected content. The issue appeared to stem from Divi’s Theme Builder potentially overwriting post variables required by shortcodes.
Solution:
A workaround was suggested due to the limitations in Divi’s handling of shortcodes within the Theme Builder. A custom PHP function was created and added to the theme's functions.php file to handle the conditional logic and output the custom field directly:
function display_reisekosten_func() {
if (get_post_meta(get_the_ID(), 'wpcf-reisekosten-pauschal-individuell', true) == '1') {
return '<h2>Reisekosten</h2>' . do_shortcode('[types field="reisekosten-min-km"][/types]');
}
}
add_shortcode('display_reisekosten', 'display_reisekosten_func');
The shortcode [display_reisekosten] could then be used within a Divi Code Module to render the content conditionally. While not a guaranteed solution, this approach provided a viable alternative until Divi resolves the underlying issue.
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 was trying to create a search functionality on their website that displayed locations based on a user's input. They had built a view that showed locations within 50 miles of the user and created a nested view to display results within 350 miles if no results were found within the initial range. However, the nested view did not trigger correctly based on the user’s input, leading to issues in displaying the appropriate results.
Solution:
We confirmed the customer's setup and created a working example to demonstrate how to achieve the desired functionality. We provided guidance on setting up the main view and the nested view using the URL parameter toolset_maps_distance_center for filtering. We also suggested moving the map markers from the block directly into the content template to ensure that the markers would rebuild when the nested view was called.
Although the customer inquired about displaying the distance from each result to the user's location, we noted that this feature was under consideration for future versions of Toolset. However, a straightforward solution was not readily available.
After implementing the changes we suggested, the customer confirmed that the nested view was functioning as expected, effectively displaying the relevant markers on the map.
The customer was working on a Custom Post Type ("Object") that represents artworks on their museum platform. They created specific content templates for different museums to cater to their unique display requirements. However, there was no option in the Custom Post Type Forms for the museum staff to assign the appropriate content template when creating or editing an artwork. The customer wanted to eliminate the need for staff to navigate the wp-admin editing page, which could lead to confusion and errors.
Solution:
We suggested utilizing a generic field in the form to enable the selection of a content template. The customer successfully implemented a dropdown select field, but encountered an issue where the selected option did not display when returning to the form. To resolve this, we provided a custom PHP function that retrieves the current template assigned to the post. The code snippet for the function is as follows:
add_action('cred_save_data', 'my_save_data_action', 10, 2);
function my_save_data_action($post_id, $form_data) {
// Array of form IDs for which the action should be triggered
$form_ids = array(21166, 18806);
// Check if the current form ID is in the list
if (in_array($form_data['id'], $form_ids)) {
if (isset($_POST['select-template'])) {
update_post_meta($post_id, '_views_template', sanitize_text_field($_POST['select-template']));
}
}
}
After further testing, we recommended that for museum editors, the solution could be simplified by hardcoding the content template ID to ensure the correct template is always assigned. This change allowed for the expected functionality when creating or editing artworks.
