Hello,
I’ve started testing WPML for compatibility with PB and found that somewhat works but it’s tricky to manage.
WPML uses standard WP posts/pages/custom post types: when you start translating something it creates a new post of the same type and marks a link between the original language post and the translated one.
The first thing you do just after is using it’s own feature to copy the content from the original post to the translated one usually checking options to copy media attachments and the featured image.
PB stores a plain copy of the posts in standard WP format so the copied content will be that, all the layouting and customizations made in PB are not copied.
As a workaround I’ve saved my page as a template, replaced it to the translated page and attached medias manually.
PB stores every piece of content/layout/options in it’s own table, may be it can duplicate that too using ‘icl_before_make_duplicate’ and ‘icl_make_duplicate’ WPML action hooks.
(Curiosity killed the cat: postmeta.meta_value is LONGTEXT theoretically providing up to 4GB of storage, why PB uses it’s own storage implementation?)
PB stores every piece of content/layout/options in it’s own table, may be it can duplicate that too using ‘icl_before_make_duplicate’ and ‘icl_make_duplicate’ WPML action hooks.
That sounds like a great solution. I’ll look into those hooks this week.
(Curiosity killed the cat: postmeta.meta_value is LONGTEXT theoretically providing up to 4GB of storage, why PB uses it’s own storage implementation?)
The builder used post meta to store layout data when we first created it (it still does as a JSON export backup). We ended up going with our own table as it made querying and working with layout fragments much easier. For example, with a complex layout, we only need to deal with a small amount of data to work with a module instead of all of the layout data had we stored it in a postmeta field. I’m sure this is debatable but if you take a look at how builder data is stored as “nodes”, you’ll see it’s quite elegant
Hi Justin,
each post can use as much meta_key as needed, data can be chunked and stored at any kind of granularity, how much using few tens of postmeta slow downs instead of a custom table?
WPML copies post meta along with content, in this case would have been compatible with no further action to be performed.
I just realized that the builder is programmed to duplicate a layout if the parent post is duplicated. It does this using post meta.
I did some testing with WPML and found that they aren’t duplicating post meta when you click the plus (+) icon to create a new translation of an existing page.
I tested that by adding a custom field (which is essentially post meta) and then created a new translation of the post. In my test, the post meta was not copied. Have you experienced that before?
Without the post meta being copied, the builder doesn’t know that it needs to duplicate the layout for that post. It does appear that WPML has a duplicate function that is different from the translate function. When using that, the layout is copied.
I’m going to see if there is a way to hook into their “Copy content from” button to see if I can get this working. I’ll let you know how that goes.
each post can use as much meta_key as needed, data can be chunked and stored at any kind of granularity, how much using few tens of postmeta slow downs instead of a custom table?
For example, if we want to work with a single module, using MySQL we can say
SELECT * FROM fl_builder_nodes WHERE node = '<NODE_ID>';
When storing all of the layout data in a single post meta field, we weren’t able to do that. We’ve found that it’s much easier to work with builder data in rows than in a single post meta field. I’m always open for suggestions, so if you see a better way we could be doing that, let me know!
WPML copies post meta along with content, in this case would have been compatible with no further action to be performed.
It doesn’t appear that they are copying post meta (unless you use the duplicate button). Do I need to turn on a setting for that to happen?
I tested that by adding a custom field (which is essentially post meta) and then created a new translation of the post. In my test, the post meta was not copied. Have you experienced that before?
I've used it in the past and remembered 'copy', but yes it works as you've found, the plus sign is not enough to duplicate metas, one way is to check the 'duplicate' checkbox and then 'Translate indipendently' on the duplicate post (otherwise the duplicate will be overwriten with the original posts content once it's updated).
For example, if we want to work with a single module, using MySQL we can say
SELECT * FROM fl_builder_nodes WHERE node = '<NODE_ID>';
When storing all of the layout data in a single post meta field, we weren’t able to do that.
From your example I don’t see problems in using: get_post_meta( $post_id, $node_id, true );
then SQL is always SQL, sure it can do much more than this and is quick by design, the feasibility of alternatives depends of what you need.
The fact that the PB dataset size for each page is rather limited wouldn’t let me discard the postmeta option at first, having enhanced compatibility with other plugins as the main advantage.
I can think of storing the whole nodes dataset as a single JSON meta_value along with a complementary meta_key to store indexes for node<->parent in JSON too.
An handler on the serverside could support delta updates so to receive and transfer only what’s needed with the clientside.
I’ve no idea of what would be the performance penalty, but if it is to say 30x from 0.01s to 0.3s it would be ok, not if it goes to seconds.
A faster alternative that comes to my mind is using http://dev.w3.org/html5/webstorage/
Manipulate the dataset on the clientside and only trasfer it to the backend when needed.
Thanks for the detailed input. We won’t be working on how data is stored right now, but I would like to get back in there later this year to refactor some things and see about speeding up how data is loaded on the frontend. I’ll definitely keep your input in mind!
The fact that the PB dataset size for each page is rather limited wouldn’t let me discard the postmeta option at first, having enhanced compatibility with other plugins as the main advantage.
We are actually using post meta for some things, that’s why WPML’s duplicate functionality works
I’m just about done getting WPML’s copy button to work with the builder. That requires a little bit of extra magic since that button doesn’t copy post meta. I should have an update containing that by tomorrow.
Thanks again for all of the input. WPML is huge so we definitely want to make sure the builder works well with it.
We just pushed an update that contains support for WPML. Let me know if you run into any issues or have any additional feedback regarding that. Thanks!
Hey, long time nothing new in here…
We are updating our website we have to decide wich translation Plugin we should use in future.
Till now we used qtranslation, qtranslationX and at the moment we are trying Polylang.
Beside the Beaver Page Builder we are useing the Beaver Builder Theme.
And we want to start useing WooCommerce and some Extentions (Product AddOn, Booking, Gift Certificate).
I red about Polylang is not fully compatible with WooCommerce and WPML will slow down my site.
So I want to know if times have changed and Polylang is compatible now, WPML runs better now or if there is some alternative!?
Hello Beaver :))
I just would like to know if I can use WPML with Beaver themes, are they compatible ? also with WPML and Woocommerce + Beaver themes ? if not what do you suggest ?
Thanks a lot for your help !!
Sandra
Beaver Builder should work with WPML as long as you use sub-directories for translations over sub-domains. However, we are not on their compatibility list page and there are some issues with Cross-domain logins.
The team are aware that we need to become WPML compatible and do have plans to do so here in the future.
In regards to WPML + WooCommerce + Beaver Builder, you will want to check with either WPML or WooCommerce regarding their compatibility. I would imagine they’re, but I believe the last time I looked into this, it required a plugin. However, this may have changed.
