This support ticket is created 7 years, 8 months ago. 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.
But then i realized that now when it is easy to divide your site into content templates, it would be rally nice if content templates could be auto wrapped with a div container with a class named after the content template:
<div class="the_name_of_the_content_template">
<!-- The content template data goes here, --->
</div>
The reason why this would be nice, is because then you can be sure that you will always have a styling handle to style the content of the content template specifically.
If I created the content template html manually then I could simple "remember" to create this div container my self, but when you use Beaver Builder, then you can't add this container your self, because the output of beaver is not edit able.
Also if you created the content template html your self you may not remember to include this container, and different developer working on the site will not remember to include this as well.
Because of this it would be nice if you could have a setting, to auto append this wrapper when ever a content template is used.
Mmmm not a bad idea indeed. However, there might be some grey areas 🙂
As you know, Content Templats can be used in a set of different ays. One way is to assign to single posts, for single frontend display. They can also be used in archives, to replace the content of the elements listed. And you can also use them as blocks of content displayed using th wpv-post-body shortcode.
One setting to wrap the Content Template output might not fit all the cases. you might want to have it in the singular frontend page, for example, but not when used in an archive, or as a content block. Yes, we could add one setting per scenario, or a way to override the setting in a particular case, but that not only defeats the purpose: it makes the GUI complex, and at some point you are nevr sure which setting is to be applied.
As you mention, we do have a filter to adjust the Content Template output Its last argument is named $kind, and it holds a value that lets you separate cases based on the current usage of the Content Template. I do think that this filter provides all what you might need, so you can wrap your output just in the case that you wish.
So although I am not against the idea entirely, I would pretty much leave this to specific cases using the API we designed for this. I can see a bunch of problems related to this having side effects with Bootstrap, and any other layout framewrk, which depends tightly on HTML structures.
Well, that is exactly why we add those API filters: so you can craft a solution that you find useful without us needing to bloat the interface with options and checboxes for such small things.