The customer purchased Toolset and WPML, set both to development mode, and wants to switch to production mode in preparation for going live with a different domain next week. They were unsure of the benefits of development mode and how to switch to production mode.
Solution:
We explained that development mode allows you to have three development licenses per production site, enabling site development and sharing WPML translation credits without needing a second license. The customer can change to production mode even in a staging environment by clicking the "change to production" icon in their Toolset and WPML account sites. If the switch does not work immediately, they might need to remove the key and re-add it as a production site.
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 reported an issue where, when opening a post for editing in two of their custom post types, they receive a message: "Missing script for creating a new template. Not able to create one." This message only appears when the editor section is disabled for those post types. The other two custom post types are functioning normally without this message.
Solution:
We attempted to recreate the issue on a fresh WordPress installation with Toolset, but we could not replicate the error, even with the editor disabled. We suggested that the issue might be caused by another plugin or a custom function in the theme. We recommended the customer test with all non-Toolset plugins disabled and a default theme. The customer found a workaround by enabling the editor and then hiding it in the Admin interface. The customer decided to monitor the situation and indicated they might open another ticket if further assistance is needed.
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.
I am trying to create a membership-based site for alumni where members can register and display their profiles. I have set up custom fields for "Contractor" (simple profile) and "Showcase" (detailed profile) but the showcase list is not displayed properly in the contractor template.
Solution:
Use the Toolset relationship feature to create a connection between the Contractor and Showcase post types. Then, display the related posts using a content template following the steps provided in the Toolset documentation.
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.
