User created a classifieds site and wants to charge users for posting an “ad” (1 month / 6 months / 12 months) using Toolset Post Forms + Toolset Forms Commerce + WooCommerce.
The form redirects to the WooCommerce cart after submission, but the cart is empty (no product/billing info shows). The setup used “product based on custom field”, however no custom field was selected/mapped, so Toolset had no product to add to the cart.
Solution:
Connect the Toolset form submission to a WooCommerce product by mapping a Toolset custom field to WooCommerce Product IDs:
On a legacy Toolset site using Layouts + Views, several Views were ordered by a custom number field. Recently, posts stopped displaying in the expected numeric order. In the View editor, the “As a number” ordering option appeared greyed out. Disabling all non-Toolset plugins did not resolve the issue, indicating a Toolset-side regression or incompatibility.
Solution:
The numeric ordering was enforced programmatically using the wpv_filter_query hook. A custom PHP snippet was added via Toolset → Settings → Custom Code to explicitly set meta_key and meta_value_num ordering.
Because multiple Views were affected, the code was adapted to apply to a list of specific View IDs, restoring correct numeric sorting across all impacted Views.
In a Toolset Block View with multiple search filters, the client wanted one specific filter (“Nur freie Zimmer anzeigen” / Available Room) to remain visible at all times, even when other filters were selected in ways that would normally hide it. Additionally, the client asked how to translate the “No items found” message.
Solution:
Toolset’s option “Show only filter options that would produce results” applies to the entire View and cannot be controlled per individual filter. Therefore, it is not possible to keep only one specific filter visible while others dynamically hide.
For translating “No items found,” the text can be edited directly in the View’s [wpv-no-items-found] output. When using WPML, the text can be wrapped in a [wpml-string] shortcode so it becomes available in String Translation
A Toolset View listing in-person workshop “event” posts needed conditional, multi-level sorting: if the user didn’t enter an origin address, results should sort by a custom “start date” field; if the user did enter an origin, results should sort by Toolset Maps distance and then by the same start-date field. The user attempted to do this via toolset_views_query_args, but it didn’t affect the View output.
Solution:
Toolset Views ordering must be adjusted via the wpv_filter_query hook (not toolset_views_query_args). Use wpv_filter_query to detect whether the distance search parameter is set; if not, force ordering by the start date meta field; if yes, apply a compound orderby with distance first and the start date second.
Hook: add_filter( 'wpv_filter_query', ... )
If toolset_maps_distance_radius is empty → orderby = meta_value_num, meta_key = wpcf-start-date, order = ASC
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.
