Scope: Prime Mover Free / Pro version
OK supposing you already exported a site using Prime Mover and you ended with a large package size? Package size is somewhat a relative figure. It varies from one user to another as it entirely depends on your upload speed connection.
Supposing your package size is 350 MB, this will appear large if your browser upload speed is only 64 kbps! As it takes so much time to upload this package.
On the other hand, if you have a 1 GB package or even 3 GB but you have 100 MBPS fiber optic upload speed or even higher. The uploading experience is a piece of cake. But it’s a different story when the uploading this size on a 500 kbps slow DSL.
So a large package size definition depends on upload connection speed. The longer it takes to upload, you could say you are dealing with a large package problem.
Clue to this problem : The time to upload notice
When you first attempt to import /upload, Prime Mover analyzes resources that checks the package type, encryption status (if encrypted), etc.. Then a heads up dialog pops-up. It looks like this:
In this process, Prime Mover automatically computes the time to upload for which in this example it takes 284 minutes! This is almost 5 hours! This is because the upload connection speed of where that screenshot is taken is very slow.
In cases like this, it is not advisable to proceed the upload via the default upload functionality of Prime Mover. It is because it will take long hours and lot of things can happen. Think about internet disconnection, browser lags, server errors, etc. Your browser cannot handle these things easily because these things can random.
Why it can be slow aside from my connection?
One reason of slow browser upload via Prime Mover is because we intentionally put delays to it in “between chunks“. For example a large upload is broken down into 10 MB chunks and after uploading each chunk, Prime Mover throttles (pause a bit) and then resume uploads.
The reason why this is done is to avoid a bigger problem – accidentally DOS (Denial of Service) attacks on the server or putting a bigger load on the server. Throttling can help resolve this issue.
Usually for smaller packages, this is tolerable and advisable. But for bigger packages, there is a better solution.
Solution: Manually upload via FTP/SFTP/SCP/Cpanel File Manager
The recommended strategy is to upload the WPRIME package to your target site Prime Mover export directory. You will need to use tools that does not depend on your browser or server limitations. These are your SFTP/FTP client, SCP (SSH copy), or your traditional cPanel File manager (or even Plesk manager in some servers).
cPanel file manager is straight forward and easy to use. If you don’t have cPanel, you can use SFTP (more secure than FTP). There are lot of free tools like Filezilla that support SFTP.
If you a bit techie and knows SCP (command line SSH copy), this is so much better. It is because CLI uploading seems to be fastest to me. If you don’t have any of these tools, you can use FTP as the last resort. It is VERY strange for a hosting company to not offer any uploading solutions. FTP should be there at least.
The objective is to upload the package to Prime Mover export directory. Once uploaded, you can then restore within WordPress admin. Simple right!? These are the steps.
Step 1. Know your Prime Mover export directory path.
- Login to your WordPress admin. If your target site is a multisite, you need to be logged-in as network administrator.
- Once logged-in, go to Prime Mover -> Packages if it is a single site. If it is a multisite, go to Network Admin first then go to Prime Mover -> Packages.
- If your target site is a single-site, this is how it looks like.
The one enclosed in red box shows your target site Prime Mover export path. e.g.
If your target site is a multisite, things will be slightly bit different. You need to specify the subsite blog ID first then press enter key. It will then loads the subsite package management page. This is how it looks like:
If you have noticed, there is a blog ID field where you need to enter or select the blog ID of the subsite. This is required to load the correct package management page of the subsite. Each subsite should have its own export directory path and package management page. Make sure you load this one by providing correct blog ID.
Once it’s loaded, you should be able to retrieve the export directory path of this subsite. This is how it looks in this example:
This is where you need to upload your WPRIME package.
Step 2. Refresh the packages
Once it’s uploaded, click the “Refresh packages” button and then you should be able to see the package. Carefully examine the package file name and all meta details, make sure this is correct and that you have uploaded it correctly.
Step3. Restore the package.
Once it’s refreshed and you are sure the package is correct, you are ready to restore. Click the “Restore package” button to start the migration or restoration of the package to the target site. This can take some time depending on the size of the package vs the speed of the server.
If you cannot see the package, then it means:
- You upload it to the wrong path. Please review again the path.
- Package might be corrupted (if you are sure it’s uploaded to correct path).
If you see the package but you cannot restore it (restore button is disabled), then it means:
- You created a wrong package for your target site. For example, you create a single site package at the source site but you restore it to a multisite. You should create a multisite package in this case.
- Or you create a multisite package and you restore it to a single site (you should create a single-site package instead).
- Or you created a multisite package for blog ID 5 but you restore it to blog ID 7 (ID mismatch, not allowed). You should create a multisite package of blog ID 5 and restore it to target subsite with blog ID 5 also.
- Package is encrypted and you are using free version. (This requires PRO version).
You will always know why the Restore package button is disabled. Simply mouse over the button and the title attribute will show the reasons. For example:
In future releases, Prime Mover will gradually become better and you should expect easier and more time -saving solutions. One plan would be to add Google drive support to upload the package directly to Google drive from your server. And then you can easily restore also directly from Google drive. This bypasses local upload speed which is usually slower than using Google drive to your hosting connection speeds.
There is no need to download and upload again to the target remote server. This way, you will save time. This feature can be added to free version in the future. This is under consideration for further study.