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.
After updating Toolset Blocks from version 1.6.14 to 1.6.15, the post date filtration functionality in multiple views on my site stopped working. The view loop output no longer displays any items in the updated environment, while it works correctly on the production environment with the older version.
Solution:
In the new version of Toolset Blocks, it is necessary to specify a value for the attribute in the date filter section of the view's shortcode. If no value is specified, the filter conditions are combined with an AND operation, resulting in no items being displayed. Removing the "meetingmonth" attribute or specifying a value for it in the shortcode resolves the issue.
I have a map and a search query on a page where the distance is hard-coded to 50 miles. If no results are found within 50 miles, I want to automatically expand the search to 350 miles without requiring the user to re-enter their address. I considered using the [wpv-no-items-found] section to trigger a second view but wasn't sure how to pass the user's address to the second view.
Solution:
You can pass the URL parameter containing the user's address from the first view to the second view. Use the URL parameter toolset_maps_distance_center to set the address in the second view, which will then perform the expanded search within 350 miles.
The customer inherited a site using an older version of Toolset with the legacy Views editor for the directory page's search and layout. When trying to export the settings and data from the old site to a new one, the Views were not available on the new site, and the Professional Profiles data was missing. The customer wanted to know how to add Views or use another method to easily set up the new site using Astra and Beaver Builder.
Solution:
The legacy Views editor was likely disabled by default on the new site. To resolve this, it was suggested to enable the legacy editor in Toolset > Settings, which allows the Views menu to be displayed. The customer was then guided to use the Toolset Module Manager plugin to properly export and import the Types and Views configurations from the old site. This process successfully restored the Views on the new site. The customer was also advised on how to use Beaver Builder for designing content templates for their directory using Toolset.
I am experiencing an error when trying to save a content template in Toolset, despite not making any changes. The error appears randomly and persists even after duplicating the template.
Solution:
The issue was traced back to a custom code snippet added in Toolset's settings, which caused a fatal error during the save process. By modifying the custom code to apply only when viewing specific post types , the issue was resolved, and the template can now be saved without errors.
The customer has two custom post types: "Providers" and "Offers," where each "Offer" is linked to a "Provider." After editing some Offers, they noticed that these Offers were no longer visible to the original Providers in their front-end accounts and appeared under the customer's admin account instead. The original Providers could no longer edit their Offers without accessing the WordPress backend. The customer wanted to know how to make the Offers appear again in the original creators' front-end accounts and whether it was possible to edit Offers from other Providers without changing the Offer ownership.
Solution:
When editing the posts in the backend, the post author was being overwritten with the current user (the customer's admin account). To prevent this, it was suggested to go to Toolset > Post Types, edit the "Offer" custom post type, and enable the "Post author" option in the Supports section. This change would allow setting the post author when editing, ensuring the original author remains unchanged, and maintaining proper ownership visibility on the front end.
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.
