SOLVED: Dynamic Data Tag in Code element: Parsing Failure

Bugs
1

There’s an issue with parsing Dynamic Data Tags from Code element with complex strings.

Of course, “Execute code” and “Parse dynamic data” for Code element are toggled ON, and code is signed.

Sample Code element, NOT WORKING

<?php
echo do_shortcode('[my-version-display key="{acf_software_key}" prefix="Version: "]');
?>

Dynamic_Data_Parser fails to parse the {acf_…} tag from this complex string.
Thus, the tag is not rendered correctly. Instead, it is passed to do_shortcode as the original string “{acf_software_key}”.

I started to debug Bricks\Integrations\Dynamic_Data\Dynamic_Data_Parser.
The issue seems to arise in find_kv_arg_position(), where the parentheses of “do_shortcode(…)” are confusing the parser.

Interestingly, if I add the {acf_…} tag in a very simple manner, the tag is parsed correctly.
And even if I don’t use the result from that simple dummy tag line, the complex string is then rendered correctly. I assume there’s some kind of tag caching involved, but I didn’t investigate.

Sample Code element, WORKING

<?php
$dummy_key = '{acf_software_key}';
echo do_shortcode('[my-version-display key="{acf_software_key}" prefix="Version: "]');
?>

PS:
This is not an urgent issue for me, as I could solve it by implementing that dummy line.
I just wanted to bring that issue to your attention.

3

Hi Matthias,
Thanks for your report!

I tested with 2.4.3 with an ACF text field resolved the tag in both cases, so I cannot confirm the cause yet.

Please share a Bricks export containing the affected Code element and the ACF field-group JSON, using sample values.

Does this happen on the frontend, in the Builder, or both?

4

Hey Stefan,

thank you for having a look into that issue.

I have to apologize.
I provided a very simplified code sample in this ticket, way less complex than I have it in my actual site. And I can’t easily provide an export, because it requires, an ACF field, a shortcode, and the Code element itself.

So I tried to provide a very simple code sample that shows the same behavior as I noticed on my site.
While doing so, I got aware that the issue only appears due to some code logic, I only have on my actual site, not in the code sample I provided earlier.
The issue comes from a PHP “if” condition syntax with curly braces.

Please test a Code element with this pretty simple code, which requires no prerequisites:

<?php
if (true) {
echo 'Current Date/Time: '.
date("Y-m-d H:i:s", intval('{current_date:timestamp}'));
}
?>

:-1:

I would expect the correct date/time to be displayed.
But the Dynamic Data Parser fails due to the PHP “if (…) {…}” construct, trying to parse everything in between the curly braces of the “if” branch.
The resulting output in this case is “Current Date/Time: 1970-01-01 00:00:00” in Builder and frontend, resulting from an invalid timestamp.
If I remove the “if” condition, and just leave the echo part, the output is correct.

To verify and confirm my observation, I tested with this modified code without the curly braces on the “if”:

<?php
if (true) :
echo 'Current Date/Time: '.
date("Y-m-d H:i:s", intval('{current_date:timestamp}'));
endif;
?>

:+1:

That works fine.

PS: I know the code is a pretty stupid sample. It’s just meant to demonstrate the parser issue.

6

Thanks for providing another example. I reproduced the issue on the frontend with 2.4.3. Your alternative if … endif syntax works as a workaround.

7

We’ve addressed this in Bricks 2.4.4, now available as a one-click update in your WordPress Dashboard.

Please read the changelog entry before updating, and let us know if you experience any issues.