A Toolset Form was used to save an iframe embed code into a custom field (event-map) using [cred_field ...], but the iframe was being stripped from the submitted content and not saved. The user had already tried allowing iframe via the wp_kses_allowed_html filter, but it still didn’t persist. The behavior had worked previously and later stopped.
Solution:
Enable iframe support in Toolset’s own Forms Content Filter so Toolset Forms stops stripping the tag:
Go to Toolset → Settings → Forms → Content Filter
Click “Select allowed HTML tags”
Enable iframe and save
Also ensure the embed code is stored in a Multiple Lines (or WYSIWYG) field rather than a Single Line field to prevent truncation/format issues.
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.
