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 - 31 through 45 (of 1,397 total)
The customer created a content template and set up custom fields to display within this template. However, the content template is not being displayed on the front end as expected.
Solution:
The issue likely stems from the theme's compatibility. The customer's theme may be a block-based theme (such as Twenty Twenty-Four), which does not utilize PHP templates. As a result, Toolset content templates cannot override the theme's default display settings. It was suggested to switch to a traditional PHP-based theme to ensure that Toolset content templates are displayed correctly on the front end.
The customer created a search view that displays two types: a custom post type (CPT) and standard WordPress posts. They needed to show only CPT entries published up to a week ago, while standard posts should be displayed regardless of their publication date. The customer struggled with configuring the date filter to apply only to the custom post type.
Solution:
We explained that it is not possible to use different date filters for different post types within the same filter by default. To achieve this, we used the wpv_filter_query hook to apply a custom code snippet that checks the post type and applies a date filter only for the custom post type ("listing"). The filter was set to show records published until 7 days ago while allowing modifications without affecting the filter criteria. The code was also updated to ensure it filtered only by the published date, not the modified date. The customer confirmed that the solution worked as expected.
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 reported an issue where a filter they created worked fine, but the sorting by "vintage" on the results page was not functioning properly. The issue was observed after clicking on the sorting option by "vintage."
Solution:
We identified that the issue was related to the "vintage_post" field, which was created and managed by ACF (Advanced Custom Fields). The sorting issue did not occur when using a Toolset custom field. As a workaround, we advised the customer to manage the "vintage_post" field with Toolset by following these steps:
- Go to Toolset > Custom Fields and click on the "Post Field Control" button.
- Search for the "vintage_post" field and click on "Manage with Types."
- Edit the Toolset View "ADVANCE FILTER" and change the column field from
This workaround allowed the sorting to function correctly using the ACF field within the Toolset View. The customer confirmed that the solution worked perfectly on the staging site.
The customer was unable to save their content template and encountered JavaScript errors when updating the Kadence Pro plugin, which prevented access to the content templates. The customer reported issues that seemed to stem from changes in WordPress 6.6, affecting Toolset dynamic sources.
Solution:
We escalated the issue to our second-tier support, who identified that the problem was due to changes in WordPress 6.6 affecting Toolset dynamic sources and resulting in JavaScript errors. We applied a workaround on the customer’s development site, which involved several steps:
- Deactivated Toolset Blocks.
- Registered a temporary custom post type for viewing templates.
- Made a minor edit to the affected template titles to enable the Update button.
- Saved the templates and then unregistered the custom post type.
- Reactivated Toolset Blocks and attempted to edit the repaired templates.
After applying these steps, the customer was able to access and edit the content templates successfully. A video was provided to demonstrate the process.
The customer confirmed that the workaround worked, resolving the issues with saving and accessing their content templates.
The customer created a Custom Post Type (CPT) with a date field and wanted to allow users to filter posts by month and/or year using a select list. The Toolset view filters did not support filtering by only month or year because the date field is queried as a timestamp.
Solution:
We explained that it’s not possible to filter by month or year directly using Toolset’s default date field filters. As a workaround, we suggested creating separate custom fields for the month and year, which could then be used in the filter. We provided a code example using the save_post hook to automatically populate these custom fields based on the selected date whenever a post is created or edited:
function auto_generate_month_year_from_date_field($post_id) {
// Check if it's the correct post type
if (get_post_type($post_id) == 'YOUR_POST_TYPE') {
// Retrieve the date field
$date_field = get_post_meta($post_id, 'wpcf-YOUR-CUSTOM-DATE-FIELD-SLUG', true);
if (!empty($date_field)) {
// Convert the timestamp to a DateTime object
$date_obj = DateTime::createFromFormat('U', $date_field);
// Check if date creation was successful
if ($date_obj) {
// Extract the year and month
$year = date_format($date_obj, "Y");
$month = date_format($date_obj, "m");
// Update the custom fields with year and month
update_post_meta($post_id, 'wpcf-YEAR-FIELD-SLUG', $year);
update_post_meta($post_id, 'wpcf-MONTH-FIELD-SLUG', $month);
}
}
}
}
add_action('save_post', 'auto_generate_month_year_from_date_field', 101);
Problem:
The customer wanted to display only posts with a custom image field in her view. However, when attempting to add a filter for this custom image field, it was not listed, nor were any other custom image fields.
Solution:
After further investigation, it was confirmed that the custom image fields not appearing in the filter section is expected behavior. We suggested using a wpv-conditional shortcode to test if the image exists as a workaround and provided a link to additional code that could help. Rita decided to rework the website to make images a required element when creating profiles.
The customer inquired whether it is possible to create content templates using Elementor.
Solution:
We confirmed that Toolset is compatible with Elementor and that it is indeed possible to create content templates using Elementor. We provided a tutorial link with a step-by-step guide, including screenshots, to assist the customer in setting it up.
The customer wanted to allow coaches, defined as CPTs, to edit their own records using Toolset Forms. He explored two potential methods but was unsure how to implement them using Toolset, especially since he uses the legacy version of Views. The primary challenge was to ensure each coach could only edit their own record without using the standard WordPress authentication system.
Solution:
We suggested using a unique URL with a secret parameter to allow coaches to access and edit their records. The steps include:
Adding a custom field (coach_secret) to each coach's profile.
Generating and sending a unique URL to each coach containing the secret parameter.
Creating a custom shortcode to handle the secret verification and display the form pre-filled with the coach's details.
Implementing a custom function to validate the secret parameter against the coach_secret field.
Here is a simplified version of the custom code used:
Problem:
The customer needed to filter posts in her directory by a custom taxonomy called Features, ensuring that only posts with all selected tags were displayed (using an AND operator instead of OR).
Solution:
We determined that Toolset Blocks does not natively support changing the operator from OR to AND for multiple select fields. As a workaround, we enabled legacy views and configured the custom search to use the AND operator. Additionally, we used custom code with the wpv_filter_query filter to change the operator to AND. The specific code was added to the theme's functions.php file, targeting the correct view_id:
add_filter('wpv_filter_query', 'custom_taxonomy_query_operator', 10, 3);
function custom_taxonomy_query_operator($query_args, $view_settings, $view_id) {
if ($view_id == 509) {
if (isset($query_args['tax_query'])) {
foreach ($query_args['tax_query'] as &$tax_query) {
if (isset($tax_query['operator']) && $tax_query['operator'] == 'IN') {
$tax_query['operator'] = 'AND';
}
}
}
}
return $query_args;
}
Problem:
The customer wants to target and apply different code to specific items in a View loop, specifically targeting items 1-6 with one code and items 7 and beyond with a different code (including adding a data attribute for lazy load).
Solution:
We suggested using the [wpv-loop-index] shortcode along with the [wpv-conditional] shortcode to conditionally apply code to items based on their index within the View loop. The provided example shows how to use these shortcodes to target items with an index less than or equal to 6 with one code and items with an index greater than 6 with another code that includes the lazy load attribute.
For example:
[wpv-layout-start]
[wpv-items-found]
<!-- Target items with index less than or equal to 6 -->
[wpv-conditional if="( '[wpv-loop-index]' le '6')"]
<div class="item">
<!-- Your code for items 1-6 -->
</div>
[/wpv-conditional]
<!-- Target items with index greater than 6 -->
[wpv-conditional if="( '[wpv-loop-index]' gt '6')"]
<div class="item" data-lazy="true">
<!-- Your code for items with lazy load attribute -->
</div>
[/wpv-conditional]
[wpv-no-items-found]
<p>No items found</p>
[/wpv-items-found]
[wpv-layout-end]
The customer reports that the "Added to Cart" message is not displaying correctly on their product page, even though a previous similar issue had been resolved. The initial troubleshooting step of toggling the AJAX add to cart buttons did not resolve the issue.
Solution:
I identified that the issue was caused by a specific line of code in the template that interfered with the wpv-add-to-cart-message shortcode:
The content on the blog archive page is not fully translated. A slider added to the archive template appears correctly in the default language (Spanish), but in other languages (e.g., English), a different slider from another plugin is shown. The archive pages sometimes show French as the default language instead of Spanish, indicating a potential conflict between WPML and Toolset.
Solution:
The customer discovered that the plugin "Post Types Order" by Nsp Code was causing the issue. This plugin created different template versions for each language and changed the default language of existing templates.
Deactivating and reactivating plugins one by one helped identify the culprit.
The customer removed the "Post Types Order" plugin, which resolved the issue.
The customer wants to display a custom field (Distributer) on a custom post page, but the field only shows "Booktopia/Amazon" regardless of the actual content, even if the field is blank. Other custom fields are working correctly.
Solution:
I identified that the issue was with the Content Template where the value 'Booktopia/Amazon' was added as plain text instead of a dynamic field.
I replaced the static text with the correct shortcode [types field='distributor'][/types] to dynamically display the field's content.
After the change, the proper distributor value is being displayed correctly on the custom post pages.
