Skip Navigation

[Resolved] wpv-post-body Shortcode Breaks Divi's New "Theme Builder" Global Footer

This support ticket is created 3 years, 2 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.

Sun Mon Tue Wed Thu Fri Sat
- - 14:00 – 20:00 14:00 – 20:00 14:00 – 20:00 14:00 – 20:00 14:00 – 20:00
- - - - - - -

Supporter timezone: Asia/Ho_Chi_Minh (GMT+07:00)

This topic contains 11 replies, has 2 voices.

Last updated by zacharyL 3 years, 2 months ago.

Assigned support staff: Beda.

Author
Posts
#1384649
screenshot.jpg

I am trying to: build out a single post page layout, as I normally would, utilizing the [wpv-post-body] shortcode to output text that is input in the body field.

Link to a page where the issue can be seen: hidden link

As I was building out the layout, everything was looking fine, until I incorporated the post body shortcode. The body output displays fine, but the shortcodes that makeup the Global Footer do not generate the modules as they are supposed to.

[Edit]: As I am actively working on this, and the bug is disruptive, I've taken the shortcode out in the live staging environment. If you unpack the Duplicator package, you'll see what I'm talking about.

#1384873

I cannot download the Package, as it is blocked.
Can you share it "with anyone who has this link" in Google Drive?
I can then download it.

It will still be private as it is hidden in above private fields.

Please also consult this DOC for Divi/Toolset compatibility, because you'd have to disable several settings you currently use in Divi, and there are a few restrictions (as well as currently some bugs in Divi) that make it more difficult to use Divi with Toolset right now.
https://toolset.com/documentation/recommended-themes/toolset-divi-integration/

I think the issue you see is related to the new Divi Product (WooCommerce) features, which are likely not working with Toolset

Also, with Divi you should not use Toolset Layouts, see https://toolset.com/documentation/recommended-themes/toolset-divi-integration/#installing-toolset

This would be like using more than one layout builder at once, which is generally the wrong approach in website building.
With Layouts, you should not Divi, generally (or opposite, you shouldn't use Layouts if using Divi)

Please consult the related DOC and it's sidebar-linked docs which can be helpful to decide what to use and how to build.

#1386161

Oh, sorry. Here's the package unrestricted: <removed as this is public>

Up until this latest Divi 4.0 release, where they opened up the Divi Builder as a full-on layout builder, we had been using the Divi Integration plugin to allow us to customize the header and footer with Toolset Layouts' parent layout. This had been working fine, but I wanted to take the opportunity, with the new updates, to experiment with Divi's new features. I was under the impression that it was preferred to allow the theme to dictate the header and footer, so I figured everything would be fine.

My anticipation was to build out the header and footer areas with the new "Theme Builder" and use Toolset Layouts to structure the content area of the posts/products/custom post types, as we've done up until this point.

So am I to understand that it's not a good idea to go about it this way? Are there any plans to allow both of these features to work together?

#1386667

I understand, however that integration is been deprecated since several years meanwhile (the one with Toolset Layouts / Divi).
Toolset Layouts in fact should not be used anymore when you use Divi, however, if you used the old integration, it is tricky to say "just disable it".
But in fact you should, if you do not plan to continue to use the old (deprecated) integration.

You would instead use Content Templates, as the Document elaborates.
There are no plans to change this, also there are no plans to integrate the new Builder experiences of Divi, instead, Toolset is focusing with strength on Gutenberg

I will take a quick look at the duplicate, however it is unavoidable that at some point, using Divi, you will have to decide which to use, and given the deprecation of the integration plugin in favor to Content Templates integration (and now major focus on Gutenberg) I have to suggest not using Layouts at all with Divi.

Can I ask if this is amongst an amount of "justifiable" work for you, or totally out of the rational amount of work you can and want to invest?
Note that - as said previously - the new Divi builder experience is not supported, as the linked doc elaborates.

It is hence even a question (now that you redesign) if you want to use Gutenberg instead, or risk to keep the older builder experience with Divi and Toolset (Risk, because this can as well stop working in future development cycles of Divi to come, I am not sure how much longer they will support the "old" builder).

The thing to take out here is, Divi is becoming more and more what Toolset once provided for it, so it is becoming less and less required to integrate both. Also with the turnaround WordPress took with Gutenberg, such Themes (and Plugins) building templates are simply becoming more and more obsolete.
Gutenberg even will plan to edit Layouts in future (meaning the entire templates) and Toolset is definitely taking the road WordPress dictates.

I suggest to re-design the website with that in mind, to stay "future proof".

I will feedback here later with what I find in the duplicate, I hope all that's needed (as a workaround) is to enable suppress_filters, I will check that.

#1387143

Unfortunately, suppress_filters didn't change anything.

My current solution has been to use content templates, as suggested, within Divi's code modules in the Theme Builder. This has seemed to workout rather nicely, as some shortcode usage isn't properly accepted by Divi, for whatever reason.

I initially tried developing out a WordPress archive without Layouts, utilizing Divi's Theme Builder, and I found the options heavily lacking, so I've opted to continue utilizing Layouts for archives and the Theme Builder for single post page layouts. This may or may not be the best solution, but it's the only one I can establish, given the existing tools.

Right now, I'm using my current project as a test case on how we should be handling Divi's new features moving forward. Given the current state, however, Divi's tools lack many of the features that we've come to rely on from Toolset, especially with the freedom of structuring WordPress archive loops in anyway we deem necessary. But we also don't want to abandon Divi, as the page builder has been quite useful in keeping our sites easily accessible for our clients.

The problem with the changes that are up and coming, is that we've spent the past two years building out our clients' sites with this framework. While we're a small team, we have been actively developing websites for all our clients in what we believed to be best practices on how to handle development utilizing both Divi and Toolset. We can't very well overhaul every one of our clients' sites, so we need to find a solution that will work for both our legacy sites, and our new projects moving forward.

I'm not 100% satisfied with how Divi handles dynamic content, and the Blog Module leaves a lot to be desired, so I'm stuck at a crossroads where I like Divi for its ease of use, and client friendliness, and I like Toolset for the freedom it gives us to build out WordPress archives and views in any way we see fit, without the need to program everything by hand.

Because there is a lot already built in Divi, with this project, it would be too much to refactor everything. As you know, Divi builds out everything in shortcodes, which are not portable to other themes. I would have to redevelop everything that I've already developed, while also learning how to work with a new theme that allows for free-form Gutenberg development. I don't see the time investment being favorable with the owners at this time.

#1387175

While I don't have a problem building out a single post page layout with Divi's Theme Builder, my primary concern is the lack of features that the Blog Module presents for WordPress archives.

Is there a Toolset shortcode that I can use to pull a specific WordPress archive that I've built with Toolset? If so, this might just solve our problem, and allow us to abandon Toolset Layouts entirely.

If not, if I used a view instead, what kind of problems should I anticipate, if any?

#1387985

Archives cannot be displayed outside archives, that is like the "core nature" of Archives, that they sit on no page but on templates that WordPress or your Theme provides, and can be styled by Views (or other software).

You can always create a View, and list posts in any way you like and then insert that View as a ShortCode anywhere

Content Templates should not be used in Divi, this is not suggested, what is suggested is to style Content Templates with Divi Builder in the old builder mode, not the new builder experience.

We do not ingrate the Theme Builder, but only the Divi "Builder" that allows you to style Posts, and that only in the old way, as it is shown here:
https://toolset.com/documentation/recommended-themes/toolset-divi-integration/#installing-toolset

Also Layouts + Theme Builder won't lead to stable results.

The only that is supported, is to create Content Templates, and style then with Divi
These Content Templates can be assigned to single posts or pages or custom posts, or, in a View loop applied to those posts in the loop, or the same in an archive (but, this won't help you design the entire archive or view, instead just those posts in that loop)

Right now, the only way to proceed with Toolset and Divi is as the Doc explains.
We are fixing actively issues in that integration, but there are no plans to integrate this further, as Gutenberg is the new focus.

I would recommend as well to express to Divi your concerns and wishes of more integration if any, so the Developers @Divi can as well take the adequate decisions as were to drive the next cycles of the Theme.
Many people now use Gutenberg, so I think their focus is as well on Gutenberg and similar features.

If you remove Layouts you still should be able to see your Archives the exact same way as Views created it, but, of course not the entire templates around it, only the actual loop and search.

Unfortunately there is no other way of (in future) develop with Divi and Toolset.
Layouts is clearly not in that equation anymore in future plans and Toolset + Divi as of how it stands now, only related to the currently made integration.

I will test again on your duplicate if I can see any form of possible solution with that post body (which does not solve the future issue of eventually using "outdated" integrations)

I will feedback asap.

#1388045

Ok, thank you for your insight. Any help with my current problem would be appreciated, but if it's out-of-scope, I will understand.

#1388565

The only way I could make it work (with the exact copy as you provided, no plugins disabled, hence strictly speaking "the wrong way" as it still uses layouts) was to use the Post Body Cell, which is mainly the reason why we implemented that cell (being the post body shortcode in Visual Editor Cells often a problem)

This is actually very similar to https://toolset.com/errata/loop-items-are-not-shown-if-a-view-is-rendered-thru-a-layout-applied-to-products/

I can not really report this as a BUG, because it's basically not suggested to use Layouts with Divi.
Also, we do not integrate with the Divi Theme Builder (at all), and it is "kind of" obsolete to use a Theme Builder (of Divi) and Layouts (which basically does the same as Theme Builder, it builds templates).

I'm BTW sure it happens only on WooCommerce Products as well, as far I saw, if such Layout is applied to any other Post type it's not happening correct?

The old integration as you use it was intended to work with the Divi Header and Footer, not with the Theme Builders's global header and footer.
You don't have that "bridge" plugin activated which we produced for this (deprecated) integration (As I see on the duplicate), so the usage of Layouts on Divi is clearly not supported.
It would be supported, but deprecated with the old bridge plugin, not leaving much space for fixes either, also being the Theme Builder used and not Divi's (back then) features, but it would be less "unsupported", if you understand what I mean.

When I activate that bridge Plugin on your duplicate, things actually do work, but of course, the new Theme Builder contents seem to load a Tod differently. At least thou the ShortCodes are executing, not as if you disable the bridge plugin (Toolset Divi Integration)

So you have a few options here I think:
- use the bridge plugin Toolset Divi Integration in a deprecated mode
- disable it and rebuild the site without Toolset Layouts but Divi
- disable Divi and instead move to a Gutenberg Theme that lets you use the latest WordPress features along with Toolset, here Layouts is not recommended neither but possible to use
- Leave it as is and move the post body content to a Field that you can render in that section
- Leave it as is and use the Post Body Cell of Layouts.

My personal suggestion is to think about future moves of all softwares, which will be clearly Gutenberg oriented.

#1388865

"I'm BTW sure it happens only on WooCommerce Products as well, as far I saw, if such Layout is applied to any other Post type it's not happening correct?"

As far as I can tell, this only happens on WooCommerce product post pages. I noticed my global footer was loading fine on the generic post pages, but I hadn't tried it with any of my own custom post types yet.

Thanks for looking into this for me, and I appreciate your insight. It looks like we're going to have to do some restructuring with how we develop sites moving forward.

#1389217

Thank you, that confirms what I saw as well.

Yes - unfortunately I think as well you will have to do some restructuring here, and I would recommend (personally, that is) to try to minimize all impact your software can have.

The way I do this is by using themes that provide no features. Instead, all Features come from plugins I use (which happen to be only Toolset).
Note that I do not even use Gutenberg (not yet, it is not ripe for complex sites IMO).

I use this theme hidden link (which you are free to use if you want, but we can't support it here of course), and put Toolset in place to do all the rest.
That enabled me to (on 4 sites I administrate and actively develop) never ever until now running into "compatibility" issues like the ones you are dealing with now.

All I need, is a functioning and bug free Toolset (which I admit is not always the case but it minimizes the impact massively).
I never needed to solve a compatibility issues with the Theme because, simply put, it provides only minimal HTML and PHP that is extremely "long term stable". Well, I may need to update to Bootstrap 4 sooner or later, but those edits would take 30 minutes, as opposed to redesign an entire site.

I hope this helps!
It also depends a lot if your developments are more "functionality oriented" or "design oriented".
My own work is usually extremely functionality driven and design comes after. I understand that this is often not what clients want nowadays, and design is often "everything".

Thank you for using and persisting with Toolset 🙂

#1389865

The problem with using a theme that offers little to no functionality, is that makes the site less accessible to our clientele, who we try to empower to edit their sites on their own, lest we get stuck in making minor modifications that would have been a simple change in a builder theme such as Divi.

I will take your insight into consideration, though, as we move forward with Toolset as a main contributing factor in our sites. Whether we continue with Divi, or not, it to be determined, but right now, we're concerned with making sure our whole development stack doesn't collapse as a result of Toolset and Divi pulling away from each other.