Hi i am just testing Blocks 1.3 beta at a site that i am updating at a testserver. Looks like some of the oldschool views ar not working anymore. I know it's just a beta but will further relase not beeing backwards compatible anymore?
e.g. hidden link Icons from related types
please delet follwoing information:
The link of the image has a closing types tag at the end
... lp-layout-icons-white-04.png[/types]"
So that I just tried to delet the closing types tag "[/types]" in the template for the view
<img src="[types field='location-icon' output='raw' resize='proportional' item='@location-show.parent'][/types]" class="lp-mitglieder" alt="" height="40" width="40"
Looks like I don't need any closing types tag anymore 😉
I know it's just a beta but will further relase not beeing backwards compatible anymore?
Hello, the upcoming release should definitely be backwards compatible. Existing Views should continue to work as expected in the new release. I suspect something else is going on - you may have found a bug or a conflict with another plugin/theme.
The link of the image has a closing types tag at the end
Okay, I see the same issue with shortcode execution in several places in the View's output, including in several CSS classnames like:
lp-shwo-programm-wrapper gala[/types]
lp-shwo-programm gala[/types]
This isn't normal. First, I'd like to rule out conflicts with the theme and other plugins. If it's okay, i would like to create a draft Page and insert the list-shows-freitag View in that page without using WPBakery. I'd like to disable all plugins except Types and Blocks, and activate a default theme like Twenty Twenty. Then I can test again. If the problem is solved, I can work backwards to reactivate the theme and other plugins iteratively until I find the conflict. Let me know if that's okay, or if you would prefer to do that yourself.
You mentioned a new testing server...I wonder if you are running into a known issue related to conditionals and PHP7's just-in-time regex parser pcre.jit:
https://toolset.com/errata/shortcodes-in-conditionally-displayed-content-may-not-be-executed-on-the-front-end/
There are a couple of workarounds for that, so if the tests without plugins and theme do not reveal the source of the problem, we can try those workarounds next.
Actually, nevermind...I just tried a few things in the betas myself and I'm able to replicate this problem in my local environment. I think we've got a bug. Let me escalate this to the developers and get it on their radar quickly. Thanks for the report, I'll keep you posted here.
I now that the theme I'am using makes probs, but wich theme does not 😛
If possible keep me up to date, thx!
Sure, I've escalated the issue to our developers and they have acknowledged the problem in the Views/Blocks betas. It seems to be related to some improvements made for parsing shortcodes. When the Types field shortcodes are placed inside other shortcode attributes, the problem occurs. We will add a fix for that in the upcoming full releases. Thanks again for the report! I think we can close here since the issue is in a beta, and our developers have acknowledged the problem.
My issue is resolved now. Thank you!
Hello, just a quick note to let you know Types 3.4 and Blocks 1.3 / Views 3.3 releases are now live, and the fix for the broken nested shortcode issue has been resolved.
