When you are restoring or exporting a site – the process suddenly stalls and is unable to continue until you get a JavaScript dialog error (sometimes not).

In addition – you might be getting runtime errors such as:

  • Uncaught Codexonics\PrimeMoverFramework\build\splitbrain\PHPArchive\ArchiveIOException: Could not open file for writing

You can also use this guide when you are getting other runtime errors aside from the known symptoms above.

Also where and when it’s stalled is sporadic or random – when you try re-running the restore/export , it will get stuck in different steps than before or in a different progress percentages.

Step 1: Check if you have Imunify360 enabled

Imunify360 is a web hosting security solution. This is added by some web hosting companies as an extension or module to their cPanel or security suites. This security software runs in real-time to scan files inside your web server. This can cause issues if you are running an export or restore. It is because while the site is restored – Imunify360 interferes with this and could stop any running migration processes. The migration processes will then appear stalled once any of its processes are killed/stopped.

To check if you have Imunify360 enabled:

  • Login to your hosting control panel.
  • Check if you have the Imunify360 module enabled. This might appear different from some web hosts but it will look like this:
  • Also, you can view this information inside your site phpinfo() output to check if the server is using this security module. You will see a section i360 in the output such as this:


Once it’s confirmed you have Imunify360 enabled, you can disable it as follows (requires access to your cPanel or Hosting panel/console) :

  •  Log into cPanel (or your hosting manager) -> Imunify360 -> Proactive Defense and check on “Detected Events” tab.
  • Try checking if Imunify360 Proactive defense has detected/flagged a Prime Mover archive processor file – /wp-content/plugins/prime-mover/build/splitbrain/php-archive/src/Tar.php
  • Once you see that it’s detected there, move the Prime Mover archive processor file to “Ignore list“. This will make the Imunify360 Proactive defense to ignore this script during runtime and prevent it from stopping the migration process.  Please see the attached screenshot below for an example of adding the Prime Mover archiver processor script to the ignore list. 
  • Once added to Ignore list, clear your browser cache and repeat again the restore process.

[OPTIONAL] If no Prime Mover script is detected under Detected Events but you have Imunify Proactive defense enabled. Please try disabling this completely before doing any migration processes with Prime Mover for troubleshooting purposes.

If you don’t have access to your server to disable this – please request this to your web hosting support. You can re-enable this module once you are not running any export and restore tasks.

Step 2: Check if the server is using any security module other than Imunify360

Sometimes the server is not using Imunify360 but using a different security solution. If this is the case – please get in touch with your web hosting support and ask this question if they are using some kind of real-time security file scanning. You should disable all of this before proceeding to any restore or export processes.

Step 3: Check if your hosts have some tight resource controls

If your host does not use any kind of real-time security file scanning solutions and you still have stalled export or restore – most likely this is due to tight resource controls implemented by your host.

You will know this because Prime Mover will bail out any timeout errors , etc. The only solution in this case is to open a ticket with your hosting company and request the following:

  • Temporarily increase timeout controls.
  • Temporarily lift any hosting resource controls in your account (e.g. request controls, etc.)

This should happen only to a few hosts. Prime Mover plugin is designed to handle timeouts even in a very restrictive shared hosting environment. Currently, this is how the Prime Mover plugin deals with this:

  • By default, Prime Mover timeout is set to 15 seconds. This is lower than most hosting timeouts which is around 30 seconds or even more. The default PHP maximum execution timeout is 30 seconds. Most hosting companies should even use a more conservative timeout, e.g. a minute or more. If a migration process needs to take more than 15 seconds – Prime Mover times out and exits this process to avoid hitting server timeout. It will then make another request so that each of the long-running processes will not exceed the hosting timeout limitations.
  • Prime Mover progress AJAX interval sends a request every 7 seconds to check the status of the restore or export process. This is very conservative and should not overload any server.
  • Prime Mover waits for one second before sending another export or restore AJAX request.
  • Only Prime Mover plugin processes are running when doing any export or restore tasks. It won’t execute third-party plugin code or themes. This is to conserve resources such as CPU and RAM while doing restore.

These controls are tested to work even with the cheapest and most restrictive shared hosting environments (including free hosting). If these controls inside Prime Mover are still not enough for your hosts – you should contact your hosting company and temporarily lift any restrictions inside your account so that you can successfully migrate sites.

Step 4: Escalate to Technical support

If you have done all the above steps and you are still having this issue – please contact us so we will know that you are having this issue. We will then find workarounds that best apply to your case.

Last updated: May 25, 2024

Was this article helpful?