"[twrap]" and "[/twrap]" displaying in front-end since last wordpress update

Loops & Logic
#1

Hi everyone,

I’m using Loops & Logics to display content on my website. It was perfect until the last Wordpress Core update (6.2.1). Since then, each Tangible Template Gutenberg block I use is displayed on the front end with [twrap] before and [/twrap] after. Do any of you have the same issue ? Does someone have a solution or a workaround ?
It is very upsetting because it gives my website a very unprofessional finish (I had to remove Tangible template blocks while I look for a solution).
I feel it’s probably a small thing but I can’t figure out what.
If someone can help I would be very very grateful ! :slight_smile: :slight_smile:

My config :
Wordpress Version 6.2.1
Theme : Custom block theme with no custom php functions
Plugins:
Advanced Custom Fields Version 6.1.6
Burst Statistics - Privacy-Friendly Analytics for WordPress Version 1.3.5
Complianz | GDPR/CCPA Cookie Consent Version 6.4.5
Content Blocks Builder Version 2.3.14
Forminator Version 1.23.3
LiteSpeed Cache Version 5.4
Redirection Version 5.3.10
SEOPress Version 6.6.3
SVG Support Version 2.5.5
Tangible: Loops & Logic Version 3.2.1
Wordfence Security Version 7.9.2
WP Crontrol

Architecture serveur Linux 4.18.0-348.7.1.lve.el7h.x86_64 x86_64
Serveur web Apache
Version de PHP 8.0.28 (Supporte les valeurs 64 bits)
PHP SAPI litespeed
Valeur maximale des variables PHP 1000
Limite d’exécution PHP 30
Limite de mémoire PHP 256M
Temps d’entrée max 60
Taille maximale de téléversement de fichier 4M
Taille maximale d’envoi de PHP 8M
Version de cURL 7.87.0 OpenSSL/1.1.1p

Database:
|10.6.12-MariaDB|
|mysqlnd 8.0.28|

#2

Apparently the latest WordPress update killed all shortcodes on all block themes :grimacing:

As far as why the twrap shortcode exists in the first place, a quick search of the forum indicates that it was added earlier this spring to get around a flaw in the way Gutenberg processes its content:

Gutenberg applies content filters such as wptexturize and do_shortcode to the entire page after all blocks have been rendered, which can corrupt valid HTML and JSON. The dummy shortcode [twrap] prevents do_shortcode from processing its inner content. This workaround can be removed if/when Gutenberg provides an option for register_block_type() to opt-out of these content filters.

I’m not sure if WordPress themselves even have a plan for how they might re-enable shortcodes. Seems like the L&L devs might need to look for an alternative approach to get around Gutenburg’s content filters. I’ll keep you informed of what I hear back from the devs.

1 Like
#3

Please update to L&L 3.2.2, which includes a fix for this issue introduced by WP 6.2.1.

3 Likes
#4

Thank you both for your replies, ant thank you to the devs who released a fix ! Seems to work on my end, I’m relieved!
Will follow the issue about shortcodes in fse templates because it seems to generate a few problems…

1 Like
#5

There are several devs working on various parts of L&L and Tangible Blocks but I should mention that the speedy release of this fix was all thanks to @eliot! :pray:

Also, in a convenient twist of fate, the removed lines in WordPress 6.2.1 were exactly the reason why the twrap workaround was necessary in the first place. So while WordPress 6.2.1 was released a little haphazardly, it offered a small blessing in disguise for L&L. :grinning: