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.
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.
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…
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!
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.
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!