NO BUG: Dynamic Data written in classic editor is rendered in Bricks

Bugs
1

Browser: Chrome 110
OS: macOS / Windows / Linux / etc.
URL: Link to a page that illustrates this issue
Video: Short screen recording that illustrates this issue (free tool: jam.dev)

Write {post_date} in a post in backend in the text-editor (classic editor). In frontend use the Brickes element post content to display this post. The dynamic data is rendered to a date 3. November 2025 (german date format).
Wrap {post_date} in classic editor into code or pre HTML = {post_date}
it is also rendered as a date in front end.

Or use the date format November 3. 2025 as a simple string in classic editor, it is rendered in front end to 3. November 2025.

I wrote a tutorial about dynamic data and could not display {post_date} as string = {post_date}.

1 Like
2

Hi Angelika,
Welcome to the forum!

You can use the :raw filter to skip parsing the dynamic data tag. On front end, it will just show as regular text (or code).

image
image2194×734 26.9 KB

Best regards,
timmse

2 Likes
3

Thank you for your reply, I will test this. But whatever: this is not the complete solution.
I had written

November 3, 2025

and the front end displays

3. November 2025

I need the original string (the first one) in the front end. I assume, that is not possible with :raw If so : how could one write this with :raw?

4

try {post_date:Fj,Y}

Where Fj,Y is the output date format

Full list of options

5

@Ferry
I don’t want a rendering by Bricks in front end in the element “post content”.
If I type {post_date} in backend texteditor it should display {post_date} in front end and not 3. November 2025. How could :Fj,Y help here?

6

If you don’t want rendering, then {post_date:raw} like timmse suggested should skip rendering

7

@Ferry

8

I’ve seen that. But it’s how Bricks works. So either;

You don’t render dynamic tags by adding :raw to it. {post_date:raw}

Or you determine how it renders by adding its specific output format to it. {post_date:Fj,Y}

  • F - A full textual representation of a month (January through December)
  • j - The day of the month without leading zeros (1 to 31)
  • Y - A four digit representation of a year
9

And how can you use :raw with this string? November 2, 2025
And btw. I know how to use dynamic data and I know the referencing page on the bricks website.

10

If you put {post_date:raw} it literally outputs just that text. As {post_date} so input {post_date:raw} output {post_date}

See this image made inside a post loop with post_date:raw

Schermafbeelding 2025-11-04 om 14.45.53

Without the :raw it translates to a date

Schermafbeelding 2025-11-04 om 14.47.34

11

@Ferry
You don’t understand the issue.
We are talking about {post_date} (solution use :raw)
and we are talking about November 3. 2025 ← this is written in plain text (no dynamic data!) inside of the text editor in the backend.

And this written text is changed by bricks in the frontend to 3. November 2025.

12

backend

backend
backend439×296 10.5 KB

front end

frontend
frontend458×374 15.6 KB

13

Then there are already two of us :smiley:

Please try changing the theme to a standard theme such as “TwentyTwentyFive” and see how your date is displayed there. I cannot reproduce the problem in Gutenberg or with the “classic editor” plugin.

14

Thad’s Odd, somehow something must understand it as a data instead of text, which both WordPress and bricks should not do.

You don’t an plugin or text correction tool for that?

As it is plain text, nothing in it should correct its value.

15

@Ferry

this! exact!

:folded_hands:

16

No plugin or something else. I will test now with 2020 theme as suggested by @timmse

Addendum:
During my tests, I assumed that both problems had the same cause. So I only tested {post_date} on a clean installation plus Bricks. And as we/I now know, this can be fixed with :raw. I hadn’t checked the written-out date in this clean installation.

17

I got it: Toolset Views causes this issue.
While testing, I tested only the dynamic data issue. But these are different issues with different causes.

Solution 1:
dynamic data solved with :raw = {post_date:raw}

Solution 2:
date format, cause: Toolset Views.

Thank you for your support.

18

As a supplement:
The written date is only parsed together with Bricks. If I write a post and publish it in the frontend without Bricks, the text is reproduced 1:1 (without formatting). So WP Views (from toolset.com) AND Bricks together cause the error. So is this a bug in Bricks after all?

A workaround to display November 3, 2025 as November 3, 2025 is as follows:
<code>November</code> <code> 3,</code> <code>2025</code>

You can take a look at the whole thing in this article.

19

No. Since the issue occurs only with Toolset, it’s not a “native” Bricks issue. Please contact the Toolset support, too. If there’s anything we can do to assist the Toolset devs, they can contact us by email at anytime.