WAIT: Broken rendering of WP post content in editor

I have a page template, and within that template I have two Wp Post Content widgets, one for WP post content as a data source and the other as Bricks as the data source, they are placed one after the other.

Some pages use bricks content others are just WP content, some both, works great on the front end. However, if I edit the bricks content, in the editor the content is rendered at the bottom of the page below all the other template content rather than at the spot where the widget is placed in the template. This is a recent change as it used to render properly in earlier versions.

Hi,
Thanks so much for your report!

Unfortunately, I cannot reproduce the issue. Please provide a screencast using https://jam.dev showing and explaining what’s happening.

Best regards,
timmse

Here is a screencast for you. https://youtu.be/qUcJ6Ejvk6Y

Thanks for the video! However, I still can’t reproduce the problem. Everything is displayed in the correct order in my case, so I assume there is some difference in your setup, but I can’t recognize it.

Please send temporary login credentials and a link to this thread to help@bricksbuilder.io using the email address you used during the purchase.

Wanted to come back to you on this as I believe I have a better idea of the cause of this rendering issue.

I have a bricks pages template for the site. I setup with an ACF custom field that I apply to all pages and posts and I can pick an option from a taxonomy to set if the pages template is rendered or not. This is a replacement for having to add exclusions directly to the template conditions, instead I just have 1 condition on the template using terms to exclude the template if set on the page/post. In this way I could just assign the exclude term in the page and set the page template not to render on specific pages. Unfortunately, although this worked on the front end this was not being applied correctly in the builder resulting is strange rendering of the page in the builder. This got worse when I tested the new 2.0 alpha on a staging site where it also caused major rendering issues on the front end too. As soon as I added the exclusions directly to the template conditions (overriding my terms condition) the pages rendered correctly in both 1.x and 2.

Conclusion is that you should look at the terms exclusion function in bricks to see if there is a rendering bug there. Hope that helps.

Thanks for the explanations. Nevertheless, it would be useful to send access data, information about where exactly we can see the problem etc. by email so that we can take a concrete look at your setup.

I have removed the function I was using due to the issue which resolved it so there is now nothing to show, you’ll just have to work from my description if you want to fix it.

Add a condition to a page template set to decline based on term set to “Hide template” (Taxonomy was created using ACF and just has two values, Show template / Hide template and assigned to pages). Once set it should work on the front end but seems to cause odd behavior in editor v1 (Problems in both for v2).

Hi @SpinDreams ,

Just to clarify, here’s what I think you’re describing:

In Bricks 1.12.3, element conditions in static areas within the builder (like the outer post content elements) were not executed/respected inside the builder, so everything was rendered regardless of condition. This wasn’t a bug, just how it always worked.

In Bricks 2.0, that behavior changed: now element conditions are respected in static areas within the builder. So the builder preview should now reflect the frontend more accurately.

However, in your case with 2.0-alpha, you might be seeing a different issue entirely: a bug where term-based template conditions aren’t applied correctly, which was reported here: WIP: Conditions to Terms won't apply after updating to Bricks v2-0-alpha.

Is this what you mean, or am I missing something? If we’re not on the same page, it’s best if you can replicate this in a minimal setup and share the exact steps so we can try reproducing it locally.