[Resolved] Shortcode in Custom Field and Brizy

[Author]

Posts

[Christian Cox]

Okay I'm not really able to see anything in my FTP directory. I can see a .ftpquota file, but I cannot change directories or see anything else, so I can't see the log file. It's probably not important. I can replicate a problem on my end - if I place a Types WYSIWYG field in a Brizy template the template fails to render that WYSIWYG field. That's the issue we are trying to solve, correct? If so, I can escalate this to my 2nd tier support team for additional investigation.

[Puntorosso]

Yes, please.
Please report also the original problem, which happen even when not using a WYSIWYG field.

"If I insert a shortcode in a Toolset custom field and use the Brizy Shortcode module directly in a post, it works.
hidden link
But if I create a Brizy template, with the same Brizy's shortcode module, assign this template to all posts, the shortcode doesn't resolve.
hidden link"

Thanks

[Shane]

Hi Puntorosso,

Christian has been out for a few days right now but once he is back he will be able to follow up with this.

We are also experiencing a high support forum so response times will be lower than normal.

Thank you for your continued patience with us.

[Puntorosso]

Ok, no problem.
Please keep me updated.
Thanks

[Christian Cox]

Please report also the original problem, which happen even when not using a WYSIWYG field.
Actually the WYSIWYG field is the only type of field that will resolve a 3rd-party shortcode when displayed on the front-end of the site, so the other fields types don't really apply here. Your example demonstrates the issue using a Toolset Types WYSIWYG field called "Shortcode test":
hidden link

For a bit more technical information, when I installed the clone of your site on my local environment I was able to see a PHP fatal error when I tried to display a WYSIWYG field inside a Brizy template:

[07-May-2020 22:57:26 UTC] PHP Fatal error:  Uncaught Error: Maximum function nesting level of '256' reached, aborting! in /path/to/site/wp-includes/plugin.php:912
Stack trace:
#0 /path/to/site/wp-includes/class-wp-hook.php(201): _wp_filter_build_unique_id('query', Array, false)
#1 /path/to/site/wp-includes/plugin.php(140): WP_Hook->has_filter('query', Array)
#2 /path/to/site/wp-includes/wp-db.php(2103): has_filter('query', Array)
#3 /path/to/site/wp-includes/wp-db.php(2123): wpdb->placeholder_escape()
#4 /path/to/site/wp-includes/wp-db.php(1173): wpdb->add_placeholder_escape('brizy-project')
#5 /path/to/site/wp-includes/wp-db.php(1244): wpdb->_real_escape('brizy-project')
#6 [internal function]: wpdb->escape_by_ref('brizy-project', 0)
#7 / in /path/to/site/wp-includes/plugin.php on line 912

So it seems there's some kind of infinite loop triggered here, which leads to the white screen I experienced and described before:
https://toolset.com/forums/topic/shortcode-in-custom-field-and-brizy/#post-1597807

Other shortcodes seem to be hit-or-miss. For example, a Types number field works well, but the wpv-post-title shortcode is simply written to the page.

I'm reporting these issues to our 2nd tier support team and will follow up when we have some additional information to share.

[Christian Cox]

Other shortcodes seem to be hit-or-miss. For example, a Types number field works well, but the wpv-post-title shortcode is simply written to the page.
It turns out I had Views and Blocks disabled when I tested the wpv-post-title field. Since this shortcode is part of Views/Blocks, obviously it won't work when those plugins are disabled. The WYSIWYG issue is still escalated to our compatibility team and I'll keep you posted as I receive more information.

[Nigel]

This should be fixed with today's release of Types 3.4.2, if you could please update and confirm.

[Christian Cox]

Hello, I'm checking in to see if you had the opportunity to confirm this fix. Please let us know if possible.