[Resolved] Plugin throws error message: incompatible archive
I’m experimenting the plugin by moving a local development site up to a subdirectory on a live web host (GoDaddy). WP 3.9.1 was installed in the subdirectory. Logged into the admin of the new site, and activated WP Clone. Made backup of local dev site, and attempted install of clone url on live web host. Received this error message:
‘The plugin encountered an error while extracting the zip file using WP’s zip file extractor,the following error message was returned:
Error Message : Incompatible Archive.
Temporary files created in /home/content/17/11571317/html/wp/wp-content/wpclone-temp will be deleted.’
What’s going on, and how do I fix this?
More info: Deleted all plugins preinstalled by GoDaddy. Only plugin running on site with Twenty-Fourteen theme is WP Clone. Still throws error message.
Should I overwrite the existing database tables (base WP install) with a backup (using WP Clone) of the db from my local dev site?
Went searching in the support forum on the error message named above. This is an old issue others have encountered before. The best workaround is described in a response by ‘eli006’ in the WP Clone plugin forum (‘post: Unable to get WP Clone to work since 2.14 release’) .
I attempted twice to upload (via SFTP) the backup zip file created by WP Clone on my dev host to my host server (target file directory: wp-content/uploads/wp-clone). No luck. The file transfer timed out twice after about 10 minutes. A call to the hosting service (GoDaddy) was not successful in resolving the problem. They said the time out was due to a limit imposed by my ISP.
Hmm….don’t want to unzip the WP Clone backup and send it piecemeal via SFTP. That defeats the whole purpose of the zip file & WP Clone plugin in the first place.
The zip file created by WP Clone on my dev server is nearly 600 MB, about 3 times bigger than a backup of my entire dev site’s file system and database. Is this typical for WP Clone? If I could get the zip file size down considerably, I probably wouldn’t time out when using SFTP to my test production server.
Hey, I have the same issue.
I tried uploading a zip file that I had on dropbox.
not working, same error
Well, the fact that you experienced the same problem as I makes us members of a club that I’m sure neither of us wishes to belong to.
I eventually installed my site successfully using the WP Clone (WPC) plugin. It took longer than my usual method of moving a site from a local to production server. I am glad that this only involved a move to a test production server. Here are the steps I took to resolve the problem.
1) The large site backup (BU) zip file created by WP Clone (WPC) tipped me off that something was amiss. Sure enough, there were several older BUs of files & db included with my site files that I eventually deleted.
2) I also deleted the large (650 MB) BU created by WPC from ‘wp-content/uploads/wp-clone’. At this point, the site was down to a size I expected (~190 MB; files & db).
3) I made a fresh BU of both site files & db using the ‘Backup WP’ plugin. Then moved those files outside my dev directory (‘htdocs’ in MAMP), thus emptying the ‘wp-content/backups’ directory.
4) Then made a fresh BU of the dev site using WPC. Zip file size was greatly reduced (650 -> 190 MB).
5) Pasting the BU url into my target site on the test production server returned the same error message as before. It was necessary to manually upload the WPC BU to the target ‘wp-content/uploads/wp-clone’ directory on the production server.
6) I discovered that my ISP set a 5-minute limit on file uploads via SFTP. Unable to upload the zip file via encryption, I resorted to unsecure FTP. That worked. Now I need to find out how to get more bandwidth from my ISP.
7) Using WPC on the production site, I restored the url. Unfortunately, not all the content from the site transferred. There were whole blocks of text cut off from pages and posts.
8) On a hunch, I imported a BU copy of the db file through phpMyAdmin, overwriting the db tables installed by the WPC restoration. I checked my ‘wp-config.php’ file, and the connections called for between the WP install & the db were proper.
9) I checked the test site, and I kept being redirected to my localhost site. This suggested that references in the test production db to the localhost url needed to be changed to the test production url. Thankfully, interconnectit.com’s ‘Search and Replace DB v3.0.0’ tool helps with changing these references. Unfortunately, the process of changing url’s with their tool took longer than usual, and threw a couple of errors which I’ve never seen before. After globally changing most of the url strings, I had to go in & change 2 db table rows using the S&R tool.
10) I then checked the site, and everything was up and running. Changed the permalinks and reactivated the plugins, and everything was good to go.
Would I use this plugin again to move a site? I would be willing to give it a try one more time using a different hosting company. The obvious pinch points were:
a) Inability to quickly restore a dev site on a production server using the WPC PI.
b) Insufficient bandwidth to move the WPC zip file up to the production server via SFTP.
c) Necessity to overwrite the db following the WPC restoration to install all the content.
d) Extra steps and time involved with changing url strings in the db.
On balance, I think my 20-step checklist of moving a site would work just as well, and take less time (about an hour).
wow, thanks for this!
I unfortunately this is way too complex for me.
and I’m not even sure that I can access my original site (long story),
I do however have a zip backup file of it, I think I’ll just find someone on elance and see if they can understand this and get it back up and running.
p.s. As you obviously have the experience, if you’re interested to do it let me know.
Thanks for your detailed instructions above. Sometimes, WPC has worked well for me, but this is the second time when I have tried to do a restore, got a timed out message, and then couldn’t get back into the target website.
I used WPC to take my website domain.com to localhost/domain.com using XAMPP. This worked well. I did lots of work on it and then went to upload it again to my internet host.
Instead of trying to install the zip from my computer up to my host, I moved the whole zip file to a new folder on my host. (I realise now from looking at WP Academy info) that the zip file should go into the root of the target site – they also say that the url cannot be changed but that can’t be right because you have to change it if you are uploading it to your host. I note also you found you had to put it into wpcontent/uploads/wpclone).
Now I am shut out of my online site because when I type in domain.com it resolves to localhost/domain.com
From what I can gather from your notes, I should use the “Search and Replace DB v3” tool (I have used it once before). I assume I should use it on the database on line and replace “localhost/domain.com” with “domain.com”? If I can at least get into the site backend, I will try the restore again.
I would appreciate your comments etc. It would be helpful if WP clone provided a bit more detail when you are using the tool.
Just to let you know I did a S & R but the site is still reverting to localhost version
OK…here was the SOLUTION. I could not access my site and the database was missing heaps of entries.
I used DUPLICATOR. I had problems with this 6 or so months ago and it always timed out. This time, apart from a couple of small tweaks it ran like a dream. The good thing is that the installer and archive both go straight into the domain root and is then easily accessible. I am now all up and going…very smooth indeed.
The interconnectit.com (IC) db search & replace tool should be uploaded to your remote host’s server under your domain. IC says to change the name of the S&R tool to a name of your choice (what they call a secret name). Once uploaded, open your browser, and type in ‘http://mydomain.com/S&R-db-secret-name’. The IC tool will appear in your browser window.
The software will prompt you to enter in the localhost domain name, and then the remote host domain name (the domain name you want to change to). Don’t mess around with going through phpMyAdmin and changing the serialized name strings in your db unless unless you have all the time in the world to spend on that activity. The IC search and replace tool does it for you.
The IC tool offers both a dry and live run. The dry run allows you to find out how many instances of your localhost domain name will be changed. But it doesn’t actually make the changes. The live run does. Takes about 5 – 30 seconds to complete.
BE SURE TO REMOVE THE IC TOOL FROM YOUR REMOTE HOST FILES ONCE FINISHED USING. If bad people hack your server and find the S&R tool, they can play havoc with your site and take you down.
Glad you solved your problem using the Duplicator plugin. A worthy competitor to WP Clone’s PI which allows more granular control over site migration.
This is the path I’ve taken using wp-clone to move from Godaddy to Hostgator:
1. use wp-clone to create backup file on godaddy hosted WP site
2. navigate to /wp-content/uploads/wp-clone/ and locate the newly created zip file and download
3. installed a fresh WP site on hostgator, installed wp-clone
4. use FTP to transfer zip file created in step 1 to root directory of hostgator server
5. use “restore from URL” feature in hostgator hosted WP site – link to zip file from step4
works like a charm! in my experience it seems that using the “restore from url” feature and trying to link to the URL hosted on the godaddy server would produce undesired results. I also noticed that I would get errors on the godaddy site when creating the backup, but the backup file DID get created and was waiting for me in the WP directory I mention in step 2.
Godaddy hosting is the worst!
Glad you found WP-Clone PI useful. I have completely abandoned it in favor of the DesktopServer stack from ServerPress. They run Apache/MySQL/PHP on an XAMPP interface. The limited edition stack is free and allows one to run 3 locally hosted sites on your computer. [That plan offers community level support.] The premium version ($) allows unlimited locally hosted sites and comes with premium support. Their quick deploy tools archive and zip an entire locally hosted site and quickly deploy them to a production server. I use Duplicator now only as a backup. The value of both the Duplicator PI & DTS’ quick deploy method is that one does not have to change serialized data strings in the productions host’s DB (what the Search-and-Replace-Database tool mentioned above does). Those software packages take care of that for you.
- The topic ‘[Resolved] Plugin throws error message: incompatible archive’ is closed to new replies.