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.
Public visitors could still view single “event” (and similar) posts even when the post author no longer had the required membership role. An initial attempt using a
user_has_cap
filter to block
read_post
didn’t work reliably with the site’s setup (YOOtheme + memberships changing roles between “Professional Member” and “Customer”).
Solution:
Moved the restriction logic to the front-end request flow using
template_redirect
. On single posts of the target CPTs (e.g.,
event
,
profile
), the code fetches the post author, checks if they hold the
professional_member
role, and—if not—forces a 404 response. This bypasses theme/layout nuances and consistently hides content by author role. The same pattern can be extended to additional CPTs (e.g.,
