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 1,438 total)
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.
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.
