Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generate auto descriptions based on Bricks pages #677

Open
jwwietsma opened this issue Jun 4, 2024 · 7 comments
Open

Generate auto descriptions based on Bricks pages #677

jwwietsma opened this issue Jun 4, 2024 · 7 comments

Comments

@jwwietsma
Copy link

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
Copy link
Owner

sybrew commented Jun 5, 2024

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.

@sybrew sybrew added [Status] Blocked Awaiting another feature or change. [Type] Third-party support labels Jun 5, 2024
@jwwietsma
Copy link
Author

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
Copy link
Owner

sybrew commented Jun 5, 2024

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
Copy link
Author

Hi,

I got a response:

Thank you for your report,

The developer is welcome to get in touch with us at [email protected] so we can provide him with a dev license

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

@sybrew
Copy link
Owner

sybrew commented Jun 14, 2024

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.

@sybrew sybrew added this to the 5.0.7 milestone Jun 14, 2024
@sybrew sybrew removed the [Status] Blocked Awaiting another feature or change. label Jun 14, 2024
@jwwietsma
Copy link
Author

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.

@sybrew
Copy link
Owner

sybrew commented Nov 13, 2024

In TSF 5.1, I'm going to add basic compatibility for the Bricks theme:

  • Templates are no longer supported for SEO or included in the sitemap unless the "Public templates" option is enabled at "Bricks > Settings > Templates > My templates."
  • Template Bundles and Template Tags are no longer supported for SEO; they weren't meant to be public anyway.
  • Lastly, when we detect a page is a Bricks template, the SEO Bar clarifies why no description can be generated.

Still, Bricks's data appears readable without excessive parsing. However, I ran out of time for WP 6.7 and Black Friday 2024, so I'm punting this issue and assigning it to the 5.1.x minor cycle.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants