-
-
Notifications
You must be signed in to change notification settings - Fork 48
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
Comments
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. 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. |
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? |
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. |
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 -- |
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:
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. |
Nice! Good to hear! |
In TSF 5.1, I'm going to add basic compatibility for the Bricks theme:
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. |
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.
The text was updated successfully, but these errors were encountered: