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 - 16 through 30 (of 17,504 total)
The customer wanted to move the "Next" pagination button to the right side of the page on their "Homepage - Testimonial Slider."
Solution:
We provided a custom CSS code to align the "Next" button to the right side. The code was added to the theme's customizer, ensuring the "Next" button appears on the right even on the first slider.
The customer was unable to disable a custom code in Toolset settings due to a 403 error caused by their hosting security system, which blocked Ajax requests to admin-ajax.php, labeling it as an exploit attempt. The firewall prevented changes that required Ajax, such as disabling custom code or modifying certain settings within the Toolset plugin.
Solution:
We identified the issue as being related to the firewall blocking Ajax requests. The customer contacted their host to whitelist the necessary URLs, which allowed them to enable and disable custom code successfully. However, the issue persisted when making changes to the search and pagination section in a view. As a workaround, we moved the CSS from the Search and Pagination section to the Loop CSS, and the problem was resolved, allowing the customer to save the changes correctly.
The customer was trying to display translated content with the same content template layout as the original language for a custom post type called 'events'. However, the content template ('CT for events') was not being saved for the translations, and it kept reverting to 'Template Dynamically Assigned…', causing the front-end display to be incorrect.
Solution:
We instructed the customer to manually assign the content template for the translated events. The solution involved:
- Navigating to Toolset > Content Templates.
- Editing the content template for Events in English.
- Switching to the Dutch language in the admin top bar.
- Selecting the custom post type (CPT) 'Event' in the content selection in the right sidebar and saving it. This procedure resolved the issue, ensuring that the correct content template was applied for the translations. The customer confirmed that the solution worked and planned to replicate it for other events.
The customer experienced an issue where a Kadence accordion, used within a Toolset View block with AJAX filters, stopped functioning correctly after filtering. The accordion worked fine on the initial page load but failed to open after AJAX filtering, suggesting that the AJAX process was breaking the accordion functionality.
Solution:
The problem was caused by the Kadence Accordion's JavaScript not being reinitialized after the AJAX content load. The supporter added custom JavaScript to the View settings to reinitialize the accordion each time the AJAX filter results were updated. The JavaScript snippet used was:
The customer had a search view that was supposed to show both custom post types (CPTs) "listings" and standard posts, based on the fields "city" and "listing category." However, when users were redirected to the search from their account, only "listings" were shown, and standard posts were not included in the results, even though they should have been.
Solution:
The issue was due to a discrepancy between the "listing category," which was set as a taxonomy for the "listings" CPT, and a custom field ('wpv-listing_category') for standard posts. The provided code was only testing for taxonomies and not for the custom field, causing standard posts to be excluded from the results. We modified the code to check both the taxonomy and custom field values, ensuring that both "listings" and standard posts would be displayed based on the search criteria.
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 has several events, each with multiple dates stored in a repeating field group. They want to display all events in a list ordered by the date of the first event. The inner view correctly retrieves the next upcoming date of each event, but they want the outer view to use the same logic to order the events by the first upcoming date.
Solution:
We explained that due to the way repeatable field groups are implemented (as child posts), the fields for the event dates belong to the child posts, making it impossible to directly order the outer events by these fields. The suggested solution is to add a field directly to the event posts that records the next upcoming event date. This field can then be used to order the event posts. To automate this process, the customer can use the save_post hook to copy the upcoming date to the main post whenever changes are made, ensuring that the data stays up to date.
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.
