Builder plugins (and themes that use them) such as SiteOrigin, Elegant Builder, Divi, and others, have become more popular.
Without beating a topic that has already been beat to death in the WordPress developer community, let me just say that my position on it is conflicted.
First, I generally agree with the assessment provided by Pippin Williamson:
The other big issue is that their use violates a primary reason for using a CMS in the first place – separating content from design. Using a builder embeds design elements into the content which is a major design flaw from a CMS site management perspective.
On the other hand, I also agree with Chris Lema – builders exist because there is a market demand for them:
Why do people want WordPress Page Builders?
Simple. They offer customers a solution for personalization that mass-produced themes can’t offer, while at a lower price than working with a professional web developer and web designer.
A bigger problem than simple compatibility however, is that there is simply no industry standardization. In the WP development community, most successful plugin developers work with WP’s core standards. That makes it easier for everyone because if something isn’t initially compatible, a couple of adjustments with filter/action hooks and you’re dovetailing seamlessly.
Not so with builders where they all do their own thing in their own way. As Pippin Williamson mentions in the above referenced article, the builder ecosystem is essentially the Wild West. That makes it impossible on the plugin side to construct “automatically” compatible solutions.
Builders are here to stay, and they have a very large audience. However, because of the lack of standardization, it’s incumbent upon the builder user to understand what they have and how it works in order to maximize compatibility rather than this falling to the plugin developer.
That being said, since some core principles are the same across the board, there are some basic elements that can be handled in a similar way, no matter which builder you choose.
Content Blocking
For the most part, WP-Members has already solved this issue by changing the priority level that the plugin runs its content filter on. Early on, WP-Members ran at an early priority so even though it changed the content, the builder would simply change it after that.
Changing the priority to come late (attempting to be later than at least most of the popular builders) solved this issue because now WP-Members runs after the builder has run.
Unfortunately, that can create another problem.
Login and Registration Form Layout
Remember how I said that builders violate a core principle of using a CMS by mixing design elements with content? That’s a problem for something like WP-Members that filters what is held in WP’s primary content variable and if the content is blocked, it replaces that content with the login form.
Basically, “builders” end up putting part of their structural HTML into the content (as opposed to it all being in the template). That means if a user is not logged in, a number of structural HTML tags that the builder has put into the content are also removed since they are part of the content instead of being part of the layout template.
Because there are dozens of different builders who all use their own markup, it is impossible for the plugin to be able to know what’s structural markup and what isn’t. Even within single builders, the layout tags can be different so something like WP-Members has no way of knowing if something should be kept.
There are two possible solutions presented below.
Simple Redirect
A very simple solution is to use the Advanced Options extension. This allows you to redirect content to a defined login page. Since you’ll be setting up a page like this to not be blocked, WP-Members’ securify() function is not going to run on the_content. So the above mentioned challenges do not apply to that page.
Using Advanced Options redirect for blocked content will redirect users to the login, then back to the originally requested page, providing a seamless experience that, from the user’s perspective, is no different than the plugin’s default process. And design is maintained because the logged out user never actually lands on the page that has blocked content.
Alternatively, you could achieve this by setting up a filter/action that uses the wpmem_redirect_to_login() function and send a user to the login page if the content is blocked. There is an explanation of how to do that here.
Re-filtering The Content
If you’re not using the Advanced Options extension or don’t want to use a redirect, a more direct way to overcome this can be done by re-filtering the content (using WP’s the_content) filter to add back various div tags that may be wrapping the content in the logged in state. This takes a little sleuthing through the generated page to determine what these tags actually are, but once you do that, applying the filter is relatively simple.
I have a generic framework code snippet you can start from. You’ll need to look at the structural HTML that your builder puts into the page when the user is logged in and compare that to when the user is logged out to determine the exact tags that are used. There are a couple of practical examples below the framework to give you an idea of how it works. It should be noted that two are specific to Enfold and Elegant Themes’ Elegant Builder – so the HTML for those will not be the same for a different builder, but the core concept is still the same.
Generic Framework
[snippet slug=builder-plugin-wrapper-generic lang=php]
Enfold Example
[snippet slug=builder-plugin-wrapper-enfold lang=php]
Elegant Builder Example
[snippet slug=builder-plugin-wrapper-elegant-builder lang=php]