The problem is that the templates that are using Page Builder don’t transfer the page content. In fact, not only does the page content not pass from the original site to the clone, but upon duplication, the original site loses its content, too (I told you you’d enjoy this).
This is a pretty funny issue. I’m curious to hear your take. If you’d like, feel free to examine the plugin options and create new clones to test any changes:
Update: The content only gets wiped out on the original blog when this option is selected in the New Blog Templates plugin:
Also, when this option is selected, any custom page templates I created with Page Builder also get wiped out throughout the network.
I hope this information helps!
P.S. Are these other Page Builder database tables missing from this option?
I know the top table in the image is Builder related (the bottom is from an old installation of DMS), but even when selected, the missing content issue still persists.
I did some digging and it looks like this is a bug with the New Blog Templates plugin. Here’s what’s happening…
The multisite version of the builder hooks into the wpmu_new_blog action to install the database table when a new blog is created.
New Blog Templates also hooks into that so its functions run last. Within their $this->copy_additional_tables(); call, they check to see if the table already exists, which it does since the builder created it.
If the table exists, they have a piece of code that clears it so they can copy the rows from the template table. Unfortunately, their code is clearing the template table and not the new site table. Here is the offending snippet…
$result = $wpdb->get_results( "SHOW TABLES LIKE '{$new_table}'", ARRAY_N );
if ( ! empty( $result ) ) {
// The table is already present in the new blog
// Clear it
$this->clear_table( $tablebase );
if ( $add ) {
// And copy the content if needed
$this->copy_table( $this->template['blog_id'], $tablebase );
}
}
In the code above $this->clear_table( $tablebase ); should be $this->clear_table( $new_table ); as the variable $tablebase is the name of the template table and $new_table is the name of the new table.
Unfortunately, this is something they will have to fix as it runs after any of the builder code so there isn’t much I can do to circumvent it. I wouldn’t be surprised to see this happen with other plugins that create their own tables.
That’s a brilliant answer–you correctly diagnosed the problem.
Sadly, I’m rarely impressed with WPMUDev plugins. They’re always taking development shortcuts that cause issues down the line. I had a similar problem when Gravity Forms was released years ago.
Thank you for your hard work. I’m sorry I keep running into snags.
You’re welcome! If you bring this up with them and they provide a solution I can implement, I would be happy to. I thought about a few ways around this but they all seem hacky and wouldn’t work for all use cases.
One thing you might consider is not copying the tables. Instead, you can use WP’s export/import functionality to copy your pages/layouts to a new site.
I came across a similar instance trying to copy sites using the new Demo Ninja plugin.
I devised a workaround for that installation that might work in this case, too: instead of network activating Page Builder, I can simply activate it on the demo site I’d like to clone.
The question is, will this cause any unforeseen issues? Either way, it seems to be working very well on my Demo Ninja-based multisite installation: http://drectories.com/ .
You should be able to activate the builder on a per-site basis without running into any issues. The Multisite version has been designed to handle network activation and per-site activation.
