Manuel Razzari

Hi, this looks like a bug. We’ll investigate and get back to you.

This https://wp-compatibility.com/installer-plugin is the plugin you’re referring to, right?

Uhm. I’ll install both on a test server, investigate, and get back to you! Thanks for the update!

Hello B_Dark, you found a bug in the plugin!

We have released a new version 0.1.6 of multisite-cloner that will fix your problem.

Please download and let me know if it works for you.

Thanks!

Thanks for the rate, appreciated!

Just to confirm if it’s a conflict, you could try disabling multisite-cloner but not “installer”…

If it’s indeed a conflict, I’ll install both on a test server, and investigate!

Hello, it looks like you have a plugin called “installer” which is causing the error. Did you try disabling or deleting that plugin? Also try disabling multisite cloner… Disable them one by one, and try again, to isolate the problem.

FWIW, this plugin doesn’t change any existing tables in your install. So even in case there was a bug, it would injury impact new sites, not existing ones.

Let me know how that goes!

This is resolved as of v 0.1.5.

Hello Pradip, we’ll look into this.

Question: what directory structure are you using for your uploaded files?

1. /wp-content/uploads/sites/{blog_id}
2. /wp-content/blogs.dir/{blog_id}
3. Other?

Thanks!

Thanks, I’ve updated the plugin with this change, and credited you in the logs ??

(You don’t need to re-download the plugin right now, as you already have the change.)

Thanks for the rockstar comment!
Which of the suggestions did you try? Loading the front end first? Or the code change?

Hello Nick, did you have any luck with those changes?

I’m out for the weekend, so will be able to look at this in detail on Monday, but for now you could try one of these:

1. Navigate to the site’s front end, then go back to the admin. That may fix it.

2. Open up multisite-cloner.php, and try changing this line:
add_action( 'init', array( &$this, 'init_multisite_cloner' ) );
into this:
add_action( 'admin_init', array( &$this, 'init_multisite_cloner' ) );
That is, replace “init” for “admin_init”.

Nick, what version of WordPress are you using?

You’re right, I hadn’t bothered to test the snippet on a single-blog install :$

I’ve now updated the snippet with support for both single site and multisite.

You’re right that the “a,b,c” approach is very na?ve, and it’s shocking to see how many plugins replicate this bug. I was just looking a “wp-clean-up” plugin which simply does a DELETE WHERE post_type = 'revision', not caring about any of these details.

The delete_terms function in revision-control is odd as well, as wp_delete_post_revision is already calling wp_delete_object_term_relationships, so I’m not sure it’s needed at all.

That said, it’s more likely that simply deleting from the posts table is enough, as usually revisions don’t touch other tables. But in case they do, we need to do it the right way!

So, armed with the knowledge from your post, I think all we need is to let WP take care of this the native way, which will also trigger deletion hooks which some plugins may use:

// Get all revisions in this blog - but not autosaves, which may include valuable content.<br />
$revision_ids = $wpdb->get_col($wpdb->prepare( "SELECT ID FROM $wpdb->posts WHERE post_type = 'revision' AND post_name NOT LIKE '%-autosave%'") );<br />
foreach ($revision_ids as $revision_id){<br />
   // This will invoke wp_delete_post, which takes care of related meta, taxonomy terms, etc.<br />
   wp_delete_post_revision($revision_id);<br />
}

I’ve wrapped this up in this snippet which deletes all revisions, including all blogs if it’s a multisite network).