Description:
Following the recent updates to Toolset Types and Blocks (and WordPress core), we experienced a site-wide breakage across 42 sites in our portfolio.
The issue stems from the shortcode parser's new strictness regarding nested shortcodes. Historically, it was common practice to pass custom field values into View parameters using the enclosing [types] shortcode inside the attribute.
The Broken Syntax:
[wpv-view name="display-contributor" contributorid="[types field='contributor-id'][/types]"]
The Symptoms:
The updated regex engine now completely chokes on the [/types] closing tag when it is nested inside the attribute string of another shortcode. It treats the inner closing bracket as the termination of the outer shortcode, causing the View to fail to recognise the value being passed into it.
Interestingly, [types] shortcodes nested inside standard HTML attributes (e.g.,
<a href="[types field='website'][/types]">
) continue to render perfectly fine. The breakage strictly occurs when nested inside other shortcode attributes.
Failed Workarounds:
We initially attempted to whitelist the shortcode using the wpv_custom_inner_shortcodes filter. However, because the core parser is outright rejecting the nested enclosing syntax before the whitelist is even evaluated, this filter did not resolve the issue.
Our Solution:
The only viable fix was to abandon the [types] shortcode in these contexts and replace it with Toolset's self-closing alternative, prepending wpcf- to the field slug:
The Fixed Syntax:
[wpv-view name="display-contributor" contributorid="[wpv-post-field name='wpcf-contributor-id']"]
Feedback for the Team:
Because updating this manually across our entire portfolio was unfeasible, we had to write a context-aware PHP script deployed via ManageWP to regex search-and-replace the database across 42 sites (carefully ignoring HTML attributes while fixing shortcode attributes).
Given how prevalent the old [types]...[/types] nesting method was in legacy Toolset documentation and user builds, it might be worth adding a specific deprecation warning or a database migration tool for this. Other agencies with large legacy Toolset portfolios are likely going to hit this exact same wall.
Hopefully, this report helps track down the parser conflict or assists other users experiencing the same frontend breakages!
