Generate auto descriptions based on Bricks pages

[jwwietsma]

I love the way the auto description functionality works. But currently it doesn't seem to recognize Bricks content. I would say the content generator is pretty clean compared to some other builders. As such I'm wondering weither there are possibilities to built descriptions based on the content inside a Bricks page.

[sybrew]

I believe Bricks doesn't store the HTML output in a standard Post content field. I won't be able to verify this and provide a workaround without access to their gated, not Open Source code.

Please see https://wordpress.org/support/topic/compatibility-bricks-builder/#post-14931411. I have not had a follow-up about that since.

Also https://forum.bricksbuilder.io/t/the-seo-framework-compatibility/19193.

If the authors of Bricks would reach out to me and hand me a copy, I could craft a filter to make this work and consider adding it as a feature to TSF itself. Though, it might come with a significant performance penalty, because we might need to regenerate the page twice (once for the meta description, once for the visitor).

Without access to the code, I cannot work on this issue. Hence, I added the "Blocked" status.

[jwwietsma]

Thanks, I have placed a request to get you a copy.

But - if you are open to it - it might be useful to have direct contact with them in regards to the way they save their HTML output? From what I understand from you they could do a better job on this as well?

[sybrew]

Thank you for that!

Yes, I hope they'll follow up. But if a plugin is Open Source, I can quickly inspect stuff whenever it best suits me, and I'd have all the answers to your questions ready. With gated code, I need to reach out to the developers every time to get the latest copy, which can take several days (sometimes weeks), often going via routes that don't support sharing code well (or at all). Tracking changes in the code is critical to my work, but that is made impossible.

Writing this reply alone takes longer than inspecting the code to find the cause of an issue.

In any case, I still suspect Bricks does not store the content in the standard Post content field. Quite a few page builders don't do this or even populate it with uninterpretable [short][codes] (looking at Divi) instead of HTML. The result is that all plugin developers keep running in circles, adding curious compatibility patches everywhere, wasting good time and energy, all while causing more issues in the process. But if the standard WordPress Post API is honored for Post content, then all plugins can quickly interact with that data without having to consider for a second what other plugins do.

[jwwietsma]

Hi,

I got a response:

Thank you for your report,

The developer is welcome to get in touch with us at help@bricksbuilder.io so we can provide him with a dev license

-- So you should be able to get a free license I guess.

[sybrew]

Thank you, @jwwietsma, I am now a proud owner of a copy of Bricks.

I perused the code and found where they stored data. My previous assumptions were correct.

From Bricks's support:

Bricks data is stored under the "_bricks_page_content_2" postmeta key. Header template data under the "_bricks_page_header_2" postmeta key. Footer template data under the "_bricks_page_footer_2" postmeta key.

The WordPress (Gutenberg) post data is already stored under the "post_content".

It's still unclear to me what Header and Footer mean in relation to the content, but I only briefly dug through the code without actually using Bricks.

I also do not know the data structure of what's stored in the metakeys. I'll mark this for 5.0.7 so that I'll get to it sooner than later.

[jwwietsma]

Nice! Good to hear! I would guess header and footer don't have much relation to the content. It are two separate template positions. Normally all main content is in content (page, post, whatever) template.