Yes, we are aware of this, and I am sorry for the delay in the solution. It was meant to be included in the first stable version, but unfortunately we had to focus on some bugs before getting our hands on this.
The main problem we face related to this is that when using Beaver over a Content Template, you probably want to use it over a post, to have a proper preview. On Content Templates used inside a View, or as a View loop, you can or should not select a usage for the Template (in View loop templates, you can not even set it, as you point out). As a result, and on a first step, we disabled the ability to apply Beaver.
To have this working we need two things. First, the ability to enable Beaver on the loop Template from within the View. And second, the ability to properly set the preview post candidates when adding Beaver for the Template. We made some progress on the second item, while the first one is still pending. But our plans are to include a complete and clean way to interact in the next release (maybe not 2.3, but 2.2.1). Finally, we have plans for a third hing: letting you enable Beaver on a Content Template without any info about where it will be used at all. As we can force that the frontend editor gets applied to no post (hence Views shortcodes will not be parsed), this should also be an option.
So long story short: we know and we are sorry. We got delayed by some other important things to manage here, but we are aware of those limitations and we have a clear roadmap on how to solve them.
Sorry for the delay, and please let me tell you that this is on eof the major Beaver Builder compatibility issues that we will have solved next.
Yes, this was not finaly included in Views 2.2.1 because it was not finished. We had to deal with some old pending and urgent issues, and some newly found compatibility problems, so we had to release with what we had completed and tested, and unfortunately this was not in neither those states.
However, I am actively working on this. The main porblem here is that the required changes might not be suitble for an errata or a small patch, since they involve editing many different files, hence it will surely be released as part of a proper version. Whether this is 2.2.2 or 2.3 as initially planned will depend on some elements, like the amount of other fixes we have on the pipeline, the testign time they require, etc. Long story short, I can not state a proper deadline for this to be out. I can tell you that we plan to release Views 2.3 before WordPress 4.7 is out, which is planned for late November. As it is still a month and a half away, we will strongly consider having a point release on the meantime.
I am raising our ticket priority to a high level too. When we have a tested version, I might contact you and offer you a beta version that will contain this new feature, plus the cumulative improvements, and thta passed through our first testing layer (but not over our full testing suite). You can check it and decide whether it is stable enough for you, or wait to the proper version.
It has been two month now since our last post here and almost half a year since we first reported the bug, and version 2.2.2 and WordPress 4.7 is already out but the bug is still there.
We are using different workarounds at the moment but as you surely see it is not a good solution and we really need you to solve the issue.
I a really sorry for the dlays around, but as first stated, this is going to get released within Views 2.3, which is in its closing stages. We already have this in place and we are just giving it the final tests with other improvements to include in the coming version, then a final QA round and a proper release. As we do have releases with other plugins in the Toolset family, we are talking about some weeks.
I know it's been quite some time, and we had some small rleases in the meantime, including a compatibiliy release for WordPress 4.7. But this is a major change, which included several extra changes in several key places, mainly on the administration of inline Content Templates inside Vies, but also on how you fire the page builders in the Content Template edit page, and especially on how the frontend preview works for Beaver.
I also know that this is being considered a bug, but in all honesty, this was not how we planned to integrate Beaver Builder on a first step. A first integration was meant to bring Beaver to Content Templates used for single posts and pages, not inside View loops, hence we had to modify several key places where we were assuming that we were in our known scenario. We are gld we did, as it now seems natural, but anyway we planned to extend the support to other usages in steps, as we have finally done.
We managed to:
- Let you select which page builder from the ones supported will be used to edit a Content Template used inside a View.
- Let you design a Content Template with a supported page builder even if it is not assigned to any usage. In that case, previews will show shortcodes without replacing them with a specific post related data.
- Use the most accurate frontend template from your theme to see the frontend editor preview.
Those are not things that we want to have, or things we are aware we are missing. Tose are things already implemented and in its testing stage.
I do hope the wait is worth it for all of you. We have big plans related to this, from expanding and improving the support of the currently integrated page builders to bring new ones to the game.
