[Remonté au deuxième échelon] Recent parser updates break nested [types] shortcodes in attributes

[Auteur]

Publications

[Simon]

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!

[Minesh]

Hello. Thank you for contacting the Toolset support.

First of all:

Could you please send me debug information that will help us to investigate your issue.
=> https://toolset.com/faq/provide-debug-information-faster-support/

[Simon]

I have provided info for one example of an affected site

[Minesh]

Here is a sandbox site and you can auto-login to it using the following link:
- lien caché

I have just run a test by creating the following view that will display the post links of property post type based on the current property post bedroom value. Here is a view:
- lien caché

As you can see with the above view, I've added the Query Filter:

Custom field filter
Select items with field:
Number of bedrooms is a number equal to VIEW_PARAM(nob)

Here is a single content template for property post where I've added the "Fields and Text" block and added the above view as given under:
=> lien caché

<h1>Related Bedrooms:</h1>
[wpv-view name="same-number-of-bedrooms" nob="[types field='number-of-bedrooms' output='raw'][/types]"]

If you can check on frontned:
- lien caché

As its 1 bedroom flad, the custom field number of bedrooms has value 1 it shows other property where bedroom has 1 value assigned.

As I'm not able to reproduce the issue, I see you are using number of third-party plugins and you need to check with only Toolset plugins active.

[Simon]

Your sandbox example uses the Block Editor for the Content Template. All our sites use Classic Editor.

Can you set up a test scenario using Classic Editor and see if that's similarly unaffected?

You're correct that we have a lot of other plugins active (as will most of your customers) but I doubt any of them are relevant, especially given as 42 different sites needed to be fixed.

Thanks

[Minesh]

Here is the legacy content template I've created to display single property post:
- lien caché

As you can see I've added the following to above cassic content template:

<h1>[wpv-post-link]</h1>



<h1>Related Bedrooms: - This property has Bedrooms = [types field='number-of-bedrooms' output='raw'][/types]</h1>
[wpv-view name="same-number-of-bedrooms" nob="[types field='number-of-bedrooms' output='raw'][/types]"]

When I check on the front end it works as expected:
- lien caché

[Simon]

If you've proved to your own satisfaction this is not an issue then good for you. I'm not convinced, because I had to fix it.

I would strongly suggest you test across a wider range of scenarios. For example, single line text fields and search strings, rather than just number fields.

[Minesh]

Its not about the satisfaction but in order to escalate the issue I need to reproduce the issue that means I need proof.

I do not have setup like you have, with hundreads of different plugins installed. That is why I urge you to minimize the cause of the issue:

*** Please make a FULL BACKUP of your database and website.***
Could you please try to resolve your issue by deactivating all third-party plugins as well as switch to the default theme (if required) to check for any possible conflicts with any of the plugins or themes?

You should try to deactive plugins one by one and check if you able to spot the plugin/theme conflict. If it does not then I will ask you for admin access details and then try to build view like you have with the same field type you have.

[Simon]

I don't have time. Sorry. I will leave this here in case someone else experiences the problem and reports a scenario you can reproduce.

I would recommend you try testing with WooCommerce installed (which is definitely a common thread of the affected sites), and that you ensure the PHP / MySQL / WordPress setup accurately reflects what I've reported.

**WP Version:** 7.0.2
**PHP Version:** 8.3.16
**Database:** MySQL v10.11.5
**Server:** Apache/2.4.57 (Unix)
**Active Theme:** ISD Distribution (v1.0) [Child of Storefront]

[Minesh]

Would you mind to share duplicator copy of your site?
- https://toolset.com/faq/provide-supporters-copy-site/

you can exclude the uploads folder while bulding the duplicator copy. Alernatively, share admin access details and allow me to take copy of your site.

I have set the next reply to private which means only you and I have access to it.

[Minesh]

I'm able to download your site and will setup that on my local machine.

In the mean time, can you please share the direct view link or view ID or page link where I can see the issue.

[Simon]

I already shared the View ID - 886

To see the problem in action, view any Book (it's a publisher site, they're not hard to find). With the bug, the author is ALWAYS shown as the oldest post of type Contributor. Without the bug, it's shown correctly based on contents of the Repeating Field Group.

[Minesh]

Ok - I'm able to reproduce this and I've escalated the issue in front of our next level support. Please hold on for further update.