I’ve been using the Page Builder (congrats for the rebrand, the landing page and mascot looks great!). I noticed a bug (or at least, an undesired behavior) in some of my projects. I have setup with some custom fields on pages. My workflow for creating a page is this:
Create a page and fill all custom fields;
Launch Beaver Builder;
Create page content / layout and save;
Done!
For this workflow, it works ok. But, every time I got back to the backend to edit my custom fields, when I update the page, everything that I created with the builder is gone! Well, almost everything: all the layout configuration made with the builder is gone, but the content still remain (inside a single editor instance), like if I had created the content before using the builder.
Is this the default behavior? I can understand that the builder preserves the content (even if you uninstall the plugin). I suppose that, when the post / page is saved at the backend, the plugin identifies it as I was edited the content too (with default post editor), and reset all the builder configuration for the post.
What do you guys think? Is this a bug? Or there is a workaround for it?
Diego, thanks for the feedback on the rebrand. It was a big decision, so your support means a lot!
The behavior you’re describing might be more of an oversight on our part than a bug. Opening the page builder from the page editor will “enable” the builder, but going back and editing the page in the WordPress editor “disables” the page builder. We didn’t account for people using custom fields and needing to edit those after the builder has been activated.
Thanks for bringing this to our attention. We’ll probably need to rethink how the page builder is enabled/disabled. For the time being, hopefully you can still edit your custom fields then go back into the page builder to “re-enable it.” Sorry for the inconvenience there. We’ll start thinking about ways to make that workflow more efficient.
Yeah, I thought that could not be a bug, but some behavior about the backend editing. Maybe there is a way to check if the user edited only the default content editor at the backend (probably there is some TinyMCE method to check it) and, if yes, disable the builder?
Let me know when you guys have a resolution for this!
Have you have been looking into this issue? I just wanted to do a quick update.
The issue continues for me, so what I’m doing is using the templates feature like some sort of “layout backup”. Everytime I update the page at the backend and the issue happens, I use a saved template to restore the layout with content.
However, as I’m working with several pages, I noticed that with some pages this issue happens, and with some other it doesn’t happen.
If you guys want to, I can give access to an installation where this issue is happening, this way you can check for yourselves what’s going on, maybe this can help.
I’m working with the plugin, and I noticed something.
I’m using several plugins on my installations. One of them is the WPML plugin, to make translated versions of the pages. The project has two languages: English (en) and Portuguese (pt_BR). The default language is Portuguese.
When I edit the portuguese version of a page, this issue almost aways happens. But, when I edit the english version of the pages, the issue almost never happens (I say almost because I’m not quite 100% sure… at least for all of the english versions that I’m working now, the issue didn’t happened).
Maybe there is some compatibility issue with WPML?
Let me make sure I understand what’s happening. If you edit a custom field on a non-WPML page it will update without disabling the builder, but if you edit a custom field on a WPML page it will disable the builder and port the content into the editor? Is that right? If so, you’re right, there might be some conflict with WPML. Let me know, we may take you up on that offer for access to the install in question.
I’m not sure how this would work if my default language on WPML was English. My installation is in pt_BR and the default language in WPML is pt_BR too.
Anyway, I did some other tests and unfortunately the issue happened in an english version of a couple of pages too.
I think that it’s best to you guys to have a look for yourselves. I’ll post here as a private reply the data to get access on the installation, and the procedures to replicate the issue.
Hey Diego, I had some time to play around in your site this morning. On my end, I am only able to recreate this issue when I add a slideshow. Updating the custom fields or the SEO metabox doesn’t affect the content from the builder. Are you able to recreate this issue when editing anything other than the slideshow?
Every page that uses the Beaver Builder has a slideshow. The slideshow on the site is built using Attachments plugin. I did some test here to check if the issue comes from that plugin. What I did is:
On the test page created, I removed the slideshow image, leaving that metabox emptu.
On the frontend, I did a quick edit to update the layout, published it and the changes were ok.
On the backend, I uptated that same page, without any changes (an still without any image on the slideshow metabox). The issue was reproduced.
So, to make sure that this plugin had something about it, I did this:
Deactivated the plugin.
Update the page layout with the Beaver Builder.
On the backet, I updated the page without any changes. The issue still is reproduced.
Dude, this is a really annoying issue, isn’t it? Not because I’m saying that has something about the builder, but because I don’t know how we can debug to get whatever is causing it!
I’ll make a quick check on all the plugins used on the site, and I’ll be back in a sec to let you know what I found, ok?
FI-NA-LLY! I think I found out which plugin is conflicting with Beaver Builder! Is Revision Control: https://wordpress.org/plugins/revision-control/. It’s a plugin that helps keep the number of revisions “on control”. It always worked fine for me, but now that I’m seeing, the last update of the plugin has more than a year (although the plugin says it works with WP 3.2 or higher). Even the slideshow works fine with Revision Control disabled. When I enable it, the issue happens even without any changes to the page. Touché!
Maybe I’ll need to find out another plugin for this feature, or control the revisions number using the old fashioned constants at wp-config.php. But at least it’s good to know what’s wrong, and even better to know that it has nothing to do with Beaver Builder!
You guys could take a loot at Revision Control plugin in some spare time to check what could be causing this issue. But for now, thank you for your attention and for taking time to check the issue!
Just a quick update on this issue: today I had some issues again. I had set up WP_POST_REVISIONS constant at my wp-config.php. The last update of the plugin (1.3.5) seems to get rid of this issue.
Diego, yes, thank you! We started encountering that problem too. The recent update should fix it, it might fix the original problem with the revision control plugin too! Sorry for the trouble on this one.
