A custom Toolset user field (wpcf-number-of-bookings) was initialized with a value of 0 when a user was created. However, when editing and saving the user from WordPress Dashboard → Edit User, the value 0 was cleared and saved as empty, even when the field type was set as a single-line text or number field. This behavior occurred consistently across multiple sites.
Solution:
A PHP hook was added to listen to the profile_update action. After the user profile is saved, the code checks whether the custom user meta field is empty or null. If so, it explicitly resets the value back to "0" using update_user_meta(). This ensures that zero values persist after saving the user profile in the WordPress admin.
The client needed to activate a Toolset license from the WordPress backend on a server that does not have unrestricted internet access. To do this, they required the specific external endpoints that must be reachable so the server firewall could whitelist them.
Solution:
Toolset license activation requires outbound access to specific Toolset-related domains. By allowing the server to communicate with the required endpoints, license activation can proceed normally from the WordPress admin area, even in a restricted network environment.
- api.toolset.com
- cloudfront.net
Whitelisting these domains resolved the license activation issue.
When exporting Toolset relationships via WP All Export, the user repeatedly hit the default limit of 100 related posts per item. They were using a legacy-style call to toolset_get_related_posts() and were unsure how to increase the limit or switch to the non-legacy approach.
Solution:
The issue was resolved by using the current toolset_get_related_posts() API correctly and passing the limit argument inside the options array. Setting 'limit' => 1000 (or another higher value) allowed exporting more than 100 related posts. The function was also updated to explicitly return post IDs and then map them to post titles for export.
A YouTube video added via Toolset was visible while editing, but it did not display on the published (frontend) page. The user had already tested with LiteSpeed Cache disabled, switched to a default theme, and kept only Toolset plugins active, but the issue remained.
Solution:
The issue was traced to the Toolset Field Group settings: the field group name used Japanese characters, which caused the View/dynamic field detection to fail on the frontend. Renaming the field group to an English (Latin) name (e.g., “post”) and saving fixed the problem, after which the YouTube video displayed correctly on single posts.
The site had two custom post types (CPTs), each with its own address field used to display markers on separate Google Maps. While CPT#1 displayed correctly, CPT#2’s map showed no markers, and the user wondered if multiple address fields were unsupported.
Solution:
Confirmed that Toolset fully supports multiple CPTs and multiple address fields. The issue was not a limitation but a configuration mismatch. The user was advised to:
Ensure the CPT#2 field is a genuine Address field (not text).
Verify the field group is assigned to CPT#2.
Configure the View/Block for CPT#2’s map to use the correct address field as its marker source.
After recreating the map and confirming the correct field assignment, markers appeared properly.
