Tale of the Cloning Tape: Cloner VS SnapShot


I just wanted to give comparison of SnapShot and Cloner since they can both do the same thing (clone sites), but with some differences.

It’s important to state that as of this post, Cloner is very new, so the expectation isn’t that it be flawless, given its only a couple of days old. Hopefully this helps users make an informed decision when attempting to clone subsites on their WP Network and also helps provide insight to the Cloner Dev Team as they guide the new plugin along its roadmap.

I also firmly believe that while to two plugins can, to an extent, accomplish the same thing, both are very necessary. At its heart, SnapShot is a subsite back-up recovery tool that just happens to be able to clone subsites; while Cloner should eventually be the de facto, standard tool used for Cloning subsites on WP Networks and beyond.

TL;DR version:

If you want to guarantee a perfect clone of a subsite on your WP Network, the SnapShot method is currently superior to Cloner. Cloner may work on less complicated WP setups, but if you’re using things like WP frameworks and tools that extend WP, then Cloner just doesn’t seem to cover all aspects of your subsite copy and also requires extra precautions be taken when it comes to email subscriber functionality and 3rd party platforming connections/pushes.

For Cloner Devs: It seems like the backup restore zip file created by SnapShot is likely the extent to which Cloner needs go to effectively copy subsite to another subsite, in order to ensure a full and exact clone. The SnapShot method also doesn’t suffer from the aforementioned “extra precautions taken” so however SnapShot is accomplishing that, needs to be forked over to Cloner as well. (Additional feature suggestions at the end of this post)


Back when SnapShot was released it was god-send to say the least and even more so as I would later find out. Its ability to compartmentalize (and even schedule) backups of individual sites on the WP Network affords a level of granular site recovery for multisite installs not offered anywhere else. Often times, the tables of a single subsite on your network go haywire and being able to restore just that one problematic subsite VS having to restore the entire network OR manually restore subsite rows and tables in phpMyAdmin (YIKES) files is invaluable; especially if the sites on your network are unrelated.

But the real kicker came when it was discovered you could actually take the SnapShot back-ups you made of any subsite and restore (read: clone) them to another existing subsite on your network!

For someone like me, who works with franchisees that are allowed to build their own local company websites, it cut down on my setup time exponentially for new franchise websites using the same template. I just clone the same boilerplate (Snapshot Restore File) to new sites and then only have to work on the small subtleties (email, phone, locations, users etc.) that need to change within the sites front-end and back-end. Nearly a flawless victory achieved.

SnapShot Method

As good as all this is, the cloning process is slightly cumbersome/clunky to conduct in Snapshot and it’s abundantly clear that it wasn’t (and shouldn’t be) the focal functionality of the SnapShot plugin. Even the main dev, Paul, at the time admitted to wanting “to keep Snapshot focused as a backup/restore tool instead of a cloning tool.”

SnapShot Cloning Pros

1) TRULY creates an exact copy of a subsite, regardless of WP Environment or the use of extended framework plugins, themes, and the like.

2) Template boilerplates (restore zips) can be downloaded, which allows for migrating subsites to other WP Network installs or even WP singles site installs where SnapShot is installed. (Note that the destination WP installs likely need to have all the same plugins, themes etc. installed to ensure a proper migration)

3) Theory: Because the copy of the site is so perfect (includes ALL of subsites tables), it doesn’t require extra precautions be taken when making a cloned subsite.

SnapShot Cloning Cons

1) The cloning process is sort of hidden and buried within the Snapshot UI and takes some figuring out since the functionally is not promoted or at the forefront anywhere.

2) Deciding which tables to potentially exclude in the clone restore file could prove intimidating for non-advanced users.

3) Cloning (restoring) a subsite to a new subsite on the network requires you to manually create that site on the network fist.

4) Cloned sites’ “Site Name” and “Tagline” settings have to be manually changed after the cloning/restoring process is completed. If you’re not paying attention to the URLs you could easily end up working on the site you cloned VS the cloned version of the site.

So the likelihood that the cloning aspects of SnapShot sees any improvements and refinements is probably nil at best. Which was “Ok” and is now completely fine because…

Enter Cloner

This past Monday I got a nice present in the form of a WPMU email stating that a new plugin Cloner had just released. I immediately reviewed the plugin page, thought: this is going to pick-up and take over where SnapShot left off, and proceeded to download the plugin to give it a test turn; after backing up my DB of course.

What I found is that while Cloner does a pretty good job of copying most stuff over, it doesn’t catch everything (at least in my setup, iThemes Builder) and thus isn’t really cloning subsites as much as its only copying over certain sections.. And because I can’t effectively tell what it is, or isn’t, copying correctly, I can’t rely on it to make perfect clones of my subsites nor make template boilerplates like I can with SnapShot.

At this point I am not all comfortable with the thought of developing a boilerplate and then overwriting one of my client sites with it.

But I want it to get there!

Cloner Pros

1) Simple interface, that hopefully remains simple even as features are added over time.

2) User-friendly exclusion options.

3) Handles the creation of new subsites as a part of the cloning process, allowing you to set a Unique “Site Name” and “Tagline”.

4) Avoids any potential conflicts with subsites that use domain mapping, not that I’ve run into any with the SnapShot Method.

Cloner Cons

1) Doesn’t actually make an EXACT copy of a subsite, at least not in my case. On the cloned site, widgets under the “Appearance” menu were listed in “Inactive Widgets” sections as opposed to their custom widget/sidebar areas. The Homepage URL was incorrect and the settings for Static Homepage and Blog Posts Page had to be manually set again.

2) Can be quirky with some plugins and site features.

3) Exclusion possibilities are pretty limited at this time.

Cloner Additional Feature Suggestions:

Batch Cloning, possibly some automation integration with Batch Create

Option to set cloned sites’ accessibility status automatically if Multisite Privacy is installed

All that said, I’m really excited about the possibilities with Cloner and will be watching closely.

Thanks for the great work as always. Cheers!

  • Michael Bissett
    • Recruit

    Hey @rone,

    Wow, that’s quite the post you’ve written, really appreciate the feedback! :smiley:

    While I’m not in a position to speak on this from a development perspective, I’ll definitely pass this along, as we’d like to make this as good as we possibly can.

    Glad you’re liking what we’ve got so far, and thanks for being a member here at WPMU DEV! :slight_smile:



    P.S. You’ll want to upgrade to the latest version of Cloner, as we’ve added integration with BuddyPress in version 1.1. :slight_smile:

  • Ignacio
    • HummingBird

    Hi @rone.

    Excellent post, thanks a lot.

    I’ll talk about Cloner as I’m not the Snapshot developer.

    As you said, Cloner does not make an exact copy of the site. Posts IDs are different for instance and it follows the idea of WordPress Importer Plugin: It tries to use always WP native functions so the data inserted in the new cloned blog is more consistent. The Con is that some themes/plugins will need some custom coding if you want settings to be copied properly. Sometimes a plugin will save a reference to a page ID, or a post ID. As this changes in the cloned blog, this data needs to be remaped.

    Cloner was born with one idea in my head: Extensibility. If you are going to need some custom coding depending on the plugin/theme, you’ll need an extensible plugin too. Cloner has many, many very well commented hooks that will help you to add that custom code in the easiest way possible. I have added BuddyPress integration with a few lines of code, for instance.

    As you said, it’s a very new plugin and I’m still working on a few improvements.



  • Ignacio
    • HummingBird

    Oh, yeah, I forgot. Cloner will be compatible with Multisite Privacy Plugin in its next release. There was some missing code when cloning the blog and blog status was not being copied.

    And also, could you open a new thread about the widgets, please?



  • Rone
    • Site Builder, Child of Zeus

    Thanks for the replies Ignacio! I’ll tackle each below.

    Cloner does not make an exact copy of the site.

    You guys might consider some asterisks or additional language on the Cloner plugin page; because I thought that’s exactly what it was going to do. It might just be semantics, by when I see “Cloner” I think “exact copy.”

    I foresee potentially a lot of people assuming that as well, not knowing that it may not cover certain plugins, themes, etc without the need for additional custom coding [extension hooks].

    Posts IDs are different for instance and it follows the idea of WordPress Importer Plugin: It tries to use always WP native functions so the data inserted in the new cloned blog is more consistent.

    I think that definitely explains this issue then. If that’s to remain as-is, then the best practices listed on that post seem like they’ll be necessary prior to cloning site using such features. No biggie.

    Cloner was born with one idea in my head: Extensibility. If you are going to need some custom coding depending on the plugin/theme, you’ll need an extensible plugin too. Cloner has many, many very well commented hooks that will help you to add that custom code in the easiest way possible.

    Awesome, is (will) there documentation providing some insight on where to begin to place those hooks within the Cloner plugin files and code?

    Also, confession, the way Cloner is presented, I really was expecting and hoping for something that handled all aspects of copying right out of the box, hassle-free. The need to conduct (or even commission $$$) additional coding to ensure that potentially every aspect of a site is properly copied and functional in the cloned site, leaves just a little to be desired. And I wonder how many people are actually going to be willing to go through and add those custom code hooks for potentially all the plugins that are already installed on their network.

    Question: Does Cloner work with any and all themes/plugins from WPMUDev without the need for hooks? Over the years I’ve gotten pretty stringent about plugins on my network and only use plugins from WPMDU & iThemes; with 3 other plugins in JetPack, Gravity Forms, and Testimonials by Aihrus.

    And correct me if I’m wrong, but those hooks are also dependent on finding the right lines of code in the installed plugins, themes, frameworks and possibly having to work with those developers to find out how to get their plugins properly registered with and “hooked into” Cloner? Its more leg work up-front (which I don’t mind), but hopefully once you do get all the hooks in, your set for life until some drastic plugin updates occur.

    Cloner will be compatible with Multisite Privacy Plugin in its next release.

    That’s awesome! Looking forward to it.

    could you open a new thread about the widgets, please?

    I’m not sure its necessary given the subsequent information you’ve provided here. It seems like its a matter of custom code needed to get Cloner hooked into the WP Framework I’m using. As I mentioned, I use iThemes Builder framework, which creates custom sidebars, and thus custom widget areas managed in the “Appearance” Menu, based on custom page layout/templates you create using the Builder framework. So unless Cloner is hooked into the custom widget areas created by Builder correctly, its likely not going to register them in the cloned site.

    Thanks again for the clarifications. I’ll definitely be keeping up with Cloner, but for now will stick with SnapShot as a matter of convenience more than anything else, for my cloning needs. :slight_smile:

  • Rone
    • Site Builder, Child of Zeus

    Just had another thought (which may be completely asinine, so forgive my ignorance in advance)…but what if there was an option within Cloner to make an exact copy of a site similar to how SnapShot does it, in addition to sort of creating just replicants like Cloner currently does?

    For those of us wanting to achieve an exact copy (Carbon Clone™ ?), some sort of advanced, nuclear, all-bases-covered option might be a nice addition. :slight_smile:


  • Ignacio
    • HummingBird

    Hi @rone.

    When I said that Cloner does not make an exact copy, well, it does, that’s the intention but the IDs are different, just that.

    The plugin is rather new so there is not many integrations with other plugins yet but I will be assisting here, in the forums, and helping with that custom code if is not very tricky (it’s not usually very tricky, just to remap some IDs), that’s why I asked you to open a new thread about the widgets, it will help us to collect information about other plugins and set a database of all custom coding (I don’t know how I’m going to do that but a Git repository would be awesome, I’d need to ask though).

    About the documentation of hooks: I know there are plans to documenting them but for the moment if you need it you can make a search of “apply_filters” and “do_action” inside cloner/copier folder. All of them have comments above explaining how you can use the hooks.



  • stephen
    • Flash Drive

    I’m new here – just got the annual plan and looking for overall improvement of my toolset and to replace a few costly tools.

    For the last year or so I’ve used Updraft Plus which works amazing well for migrating sites. Copies all themes, plugins, and remaps URL references… because of this i’m now able to easily setup test bed sites and workout the kinks before integrating into my live sites.

    I was hoping that Cloner or Snapshot could replace Updraft Plus, but from reading this post it appears either will miss plugins, themes, or other data.

    Though one comment says cloner copies everything – just ids might differ. That would not be a huge deal for me… the only place I think this would be an impact is to edit widgets that display based on page/post ids.

    Maybe some of you have experience with Updraft and have a better behind the scenes understanding… maybe Cloner would be a good replacement?

    My annual renewal is coming up in another 10 days, so hoped to drop, but maybe best to sign up for another year and wait for Cloner to develop.

    Any thoughts appreciated!

    thank you!

    ps: not using multisite – just a lot of small sales, product delivery, training, courseware type of sites – audio video downloads…

  • Ignacio
    • HummingBird

    Hi @stephen.

    The plugin has been improved in some areas, this thread is old now.

    Actually posts, pages, attachments, custom post types and terms (categories, tags and custom taxonomies) keep their IDs in the destination blog.

    This does not happen with menus for the moment.

    The plugin is bundled with some code that allows integration with other plugins, and is growing. As soon as I detect an incompatibility with a plugin I provide the code needed or, if the plugin is used by many people, I include the code in Cloner.

    I hope this works for you.



Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.