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.
Viewing 15 topics - 1 through 15 (of 17,707 total)
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.
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 wanted to add or delete a funder's name/logo to/from a dropdown list on a page. They were unsure how to achieve this and lacked guidance from the previous developer.
Solution:
We found that the dropdown is hard-coded in the child theme's functions.php file. Adding an image directly into elements of a dropdown is not supported by browsers. We suggested using a library like Select2 or Chosen for advanced customizations that allow images in dropdowns, but this requires significant code customization, which falls outside our support scope. We advised the customer to contact a Toolset contractor for further assistance.
The customer wanted to make a grid view on their website's tenders page more mobile-friendly. The desktop view looked good, but the mobile view was not user-friendly. The customer preferred the text to appear directly below the headings for each column on mobile devices.
Solution:
After reviewing the setup, we identified that the grid view was already responsive. To improve the mobile display, we suggested placing the headings and their corresponding text within the same parent block instead of using separate blocks for each element. This adjustment ensured the text appeared directly below the headings on mobile devices. We also recommended updating the padding and margins to achieve the desired look. The customer confirmed that the solution worked perfectly.
The customer wanted to enable users to filter archives on their website hosting academic texts, similar to how search results can be filtered. The customer specified that they needed the ability to filter texts by various criteria like publication year and language when viewing a specific category of texts. While they could easily set this up in a search view, they were unsure how to implement it in an archive view.
Solution:
We guided the customer to utilize the "Screen Options" tab available when editing the archive. By expanding this tab, they could enable search sections that are typically used when editing a View. This feature had been previously introduced in a pop-up when they first created a custom archive, which they may have dismissed.
The customer was advised to explore these options to achieve the desired filtering functionality for their archives.
The customer was attempting to upgrade their website to PHP 8.1 but encountered a fatal error that disappeared when Toolset Views was disabled. The error prevented the homepage from displaying images and text properly.
Solution:
After investigating, it was determined that the error was related to a specific line in a Toolset View, particularly concerning the sm-homepage-image field. Testing on a minimal setup confirmed that the issue persisted even with only Toolset plugins enabled.
Further investigation revealed that switching to a different theme caused additional errors due to an undefined function (create_function()) in the custom functions file of the theme. The customer was advised to back up the custom-functions.php file before switching themes to avoid losing custom settings.
The root cause was identified as a custom uploads location on the server, which led to an error within the Toolset plugin. A temporary workaround was implemented by modifying the Attachments.php file in the Toolset Blocks plugin, allowing the site to function correctly again.
The customer was informed that this fix would be included in an upcoming Toolset version, but they might need to reapply the workaround after future updates until the official fix is released.
The customer reported an issue where the navigation on a page wasn't functioning correctly when the user was not logged in. The problem was traced to a lock icon appearing on the 'rating' field when users were not logged in. This lock was initially thought to be added via Toolset settings, but it was later discovered to be caused by a third-party plugin called "Restrict Content" by StellarWP.
Solution:
After identifying that the lock icons were being added by the "Restrict Content" plugin, we suggested temporarily disabling the plugin to confirm that it was the cause of the issue. The customer confirmed that the issue disappeared when the plugin was disabled. Since the plugin caused the issue, we recommended contacting its support team for further assistance. As a workaround, we provided a custom CSS code snippet to hide the lock icons from the outside of the table, allowing the page to function correctly even with the plugin enabled:
The customer reported that markers on their map view were not showing up. Clusters appeared, but clicking on them did not display individual markers. The issue occurred without any recent changes made by the customer. Console errors were present on the production site.
Solution:
The customer created a staging site where the markers displayed correctly, and the console errors were resolved. After further investigation, the customer discovered that a plugin compressing and converting images was causing the custom marker images not to display properly.
