[Gelöst] Please use single.php when editing content template in beaver builder
This support ticket is created vor 7 Jahre, 6 Monate. There's a good chance that you are reading advice that it now obsolete.
This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.
Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.
No supporters are available to work today on Toolset forum. Feel free to create tickets and we will handle it as soon as we are online. Thank you for your understanding.
I have started to use beaver builder with the beaver builder theme, instead of using Layouts because of the conflicts with Layouts + Beaver Builder page builder.
When I edit a content template in beaver builder, the page loaded is page.php and not single.php
Since you must select a post type to edit the content template, you should base the visual layout upon single.php or single-<cpt name>.php file
Because if the single.php file includes a sidebar then the visual area will be limited when the page is viewed and not while you are editing the content template.
We are aware of the related issues here and we have them in our roadmap already. Just for the sake of documenting it, let me explain what is happening.
We are not loading the page.php template, but one dummy PHP template that we provide ourselves. The reason is simple to explain: we only manage theme templates, inside the native hierarchy, when we do know that they contain a call to the the_content() function. This is because when we fire the Beaver frontend editor over a Content Template, we do need that function to be called, so Beaver can hook into it.
By design, Beaver hooks there, so it seemed a good idea to double check that the function was used in the PHP template that we were about to use.
But a side effect is what you are experiencing. More and more themes, including the Beaver Builder native one, do not call the_content() on the single.php or single-{post-type}.php templates, but on subtemplates that they load on demand. Hence, our check fails and we end up loading our dummy PHP template.
This can be considered as a conservative way of building the integration. We have plans to move to a more optimistic one, where we will simply check whether the PHP templates following the WordPress hierarchical structure do exist, and trust that they will eventually load the the_content() function. That will bring better compatibility with the Beaver native theme, along with lots of others.
We still need some time to iron the dead ends here, but this should be included in our next major release.
BTW: this the_content business, was one of the issues I had with Layout. If I had a plugin which hooked into the_content , then in layouts the plugin output would be placed in every cell of the page.
I had this issue with WooCommerce Sensei and with a social login plugin, which placed share buttons all over the place because they have hooked into the_content.
So I think you should try to go for something else than relying on the_content, because there are just so many not great plugins out there.
I am honestly disappointed that WooCommerce Sensei did this, and even worse they did not prefix their custom post type names, so I ran into conflicts with other plugins with the same bad habit.
I did not expect that from a company owned by Automattic. But that is a different story.
I can tell you, there is nothing in this world that would make me happier than not needing to depend on this the_content thing. But... the platform is as it is, and we have not many alternatives. We did find some, I must say, in a clever movement so you can use Content Templates in wpv-post-body shortcodes without passing the output on that call, at least in some circumstances.
We are basically replicting what it shoudl do, but we do not allow third parties to mess with it. It is like our "private" copy of the thing, so we can control what happens. Unfortunately, as I say we can only be happy and use it in special cases, and everywhere else we are more or less chained to the platform.
Anyway, I will be working on this issue during this week. We can keep this ticket open just so you know when we have any news on it. But I suspect tht the changes will be big enough as to not be able to provide a clean patch, so maybe until the release that holds them this will keep on being a problem.
