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 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 is working on a website with two different types of listings—one created using another plugin and the other using Toolset. They wanted to know if it is possible for both custom post types (CPTs) to share the same fields and taxonomies, which are currently attached only to the custom post type created by the other plugin.
Solution:
We clarified that if the customer wants to have identical CPTs in both Toolset and another plugin, it might be best to convert the existing types and fields so that Toolset manages them, ensuring everything is centralized in one place. We provided a link to the relevant documentation for converting existing types and fields to Toolset control. Additionally, we mentioned that in some cases, it is possible to use custom fields in Toolset even if they are not managed by Toolset, but this would need to be checked on a case-by-case basis.
We document known issues and their solutions in Toolset errata. Save time by checking there first and seeing if what you are facing is a known issue. This list is kept short. We do our best to resolve all known issues with every release of Toolset plugins.
Support Policy
Toolset staff will help you use the Toolset plugins correctly, provide any information you need, help troubleshoot problems and advice on best-practices.
Please make sure to issue only one topic per each support ticket.
