Support

This is a limitation of how most FTP servers work and how PHP works.

Problem 1: Blocked by FTP server. In order to avoid server timeouts, the site transfer (essentially: a backup) has to be performed in multiple small steps. On each step we have to connect to the remote FTP server, log in, transfer a few files, log out. This roughly means that we have to do this log in, transfer, log out routine 3-4 times per minute over several minutes (or hours). This tends to cause most FTP servers to consider this behaviour as an attack and block logins from this IP for a while. The next time we try to connect to the FTP server we are blocked and the site transfer fails.

Problem 2: Large files. The definition of "large" mostly depends on the transfer speed between your original and your target servers. If a file takes too long to transfer it is possible that the FTP server closes its connection. It is also possible that, before that, PHP runs into a timeout and halts. In both cases it cases site transfer failure.

When this happens we recommend an easier, alternative method to transferring your site. Create a regular backup profile and use the "Upload to Remote FTP Server" or "Upload to Remote SFTP Server" to transfer the backup archive to the new host. As a precaution, you are advised to set the
Part size for split archives in the Archiver Engine configuration pane to 20Mb or smaller. After the backup is complete the backup file(s) will be transferred to the new server. Just upload Kickstart into it and run Kickstart. This method uses far fewer FTP connection requests than the Site Transfer Wizard, it's faster (usually: five to ten times faster!) and only requires you to upload 1 file manually.

I already told you what the possible problems could be. Let's start with the easiest issue, #2. Make sure that your origin server has a large PHP timeout (90-120 seconds at least) and that Apache is configured to have a timeout larger than PHP's.

If that doesn't work, you'll have to check that your target FTP server doesn't block connections if too many connect attempts originate from the same IP address. I can't help you with that, I am not your host.

> Quite frankly, if the STW does not work on most FTP servers and you can't give us the requirements for it to work, it really shouldn't even be published.

I disagree. It is a great way to transfer sites within the same server. Moreover, if you are strictly speaking, all web software doesn't work on MOST servers. Even Joomla!. It needs specific web software, PHP versions etc. Does this mean that no web software should ever be published because it can't work on MOST servers in the world?

> I would like to recommend that you change the STW or add an option to utilize the Upload to Remote FTP Server (which does work), include the transfer of kickstart and create a link to open kickstart on the target site.

It is being already considered. However, uploading Kickstart would potentially expose a security hole on your site. As you know, you can only upload files which are present on the source site. This means that we'd have to put kickstart.php on your source site, in a rather predictable location. If for any reason that folder is not properly secured (which could happen on many servers for various reasons) you would have a gaping security hole on your site.

I understand that you prefer convenience, but we prefer security. Unless we can guarantee that no security hole will be opened we won't offer an convenient, but insecure, feature.

When you get this message it means that this command:

$res = @ftp_put($this->_ftphandle, $realname, $sourceName, FTP_BINARY);

has failed. When the error message is produced we have established that $sourceName is a readable file, so there's no question whether that files exists. We not, however, told why the upload failed, this is a limitation of PHP. I do however see this time discrepancy:

DEBUG   |131216 20:15:10|  Adding installation/angie/language/et-EE.ini; Next offset:164960
ERROR   |131216 20:16:40|Uploading installation/angie/language/et-EE.ini has failed.

PHP is trying to upload a file of 10Kb for 90 seconds. As you are on the same server there is no way it can possibly take that long. It's also impossible that you have a networking issue (the network isn't used on loopback connections). This leaves us with the only possible reason: the FTP server, for some reason, doesn't respond.

If that file was uploaded on your server, your FTP server didn't send a 2xx successful response back to PHP. As a result PHP doesn't know if the upload succeeded, which is why the transfer wizard fails.

If that file wasn't uploaded on your server, your FTP server didn't send a failure response back to PHP. As a result PHP doesn't know if the upload failed, which is why the transfer wizard fails.

Both of these conditions occur inside the remote FTP server software. There's nothing I can do in my code to prevent, detect or work around it.