The customer encountered a message related to a Toolset license key and needed assistance to understand how to manage site registration and the use of the key.
Solution:
We explained that if the site is registered as a development site, it must be "published" to convert it to a production site. This can be done from the WordPress dashboard or the Toolset account page. The license key is used to validate the Toolset license and can be entered via the WordPress admin under Plugins > Add New > Commercial tab > (Un)Register Toolset link. The green check marks indicate that the plugins are up-to-date, while red checks signify that updates are needed.
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.
