Note: Do this test on a test system in order not to update a live site.
On a current staging, update Joomla! using the Joomla! update component with the installation method "Write files using FTP" and following custom URL:
http://test5.richard-fath.de/list_test4.xml
(The custom URL is necessary for being offered an update when already being on staging = 3.6.0-dev. The container behing it is a normal update package to current staging as it is now, 2016-05-05 17:36 CEST)
You have to enter correct acess information in the corresponding fields after having selected method "Write files using FTP", and in your global configuration, FTP also has to be switched on and be configured with the same account information.
The update is started.
The update start fails with message about invalid host or port.
Not really relevant.
The reason for the issue is the variables "$this->host" and "$this->port" being empty strings when function "ftp_connect" is called.
You can verify this by adding the following code line
error_log('Test 1: useSSL=' . $this->useSSL . ', host=' . $this->host . ', port=' . $this->port);
before the 2 occurances of the following code lines in file "administrator/components/com_joomlaupdate/restore.php":
if($this->useSSL) {
$this->handle = @ftp_ssl_connect($this->host, $this->port);
} else {
$this->handle = @ftp_connect($this->host, $this->port);
}
You will then see in your PHP error log (if logging to file is switched on in your PHP settings) that these variables are empty strings.
Before PR #9612 with the new functionality for the update component was merged, means on a 3.5.1 or older, this error was not visible, because the "direct write" method always has been used, regardless whether FTP method was chosen or not.
You can see this by adding following code to file administrator/components/com_joomlaupdate/controllers/update.php, function _applyCredentials(), at line 328:
JFactory::getApplication()->getUserStateFromRequest('com_joomlaupdate.method', 'method', 'direct', 'cmd');
This will make it use FTP mode, as it has been added to staging with PR #9612 , and then udpate will fail with invalid server name.
If you do not add this code on a 3.5.1 or older and use invalid FTP access information, e.g. invalid username, you will see that the update will be started, because FTP will not be used. I do not know how far this error goes back in history, but at least on a 3.4.8 I can confirm it.
Additional info: The temporary script "restoration.php" contains as long as it exists ftp access info with server and user and password being an empty sting.
Is this still relevant for 3.5.2 (staging) as com_joomlaupdate is very different
Status | New | ⇒ | Information Required |
Yes, still relevant with the new updater functions, see additional comments of the issue description:
When PR #9612 will be merged, this error will become more visible, because then the FTP method will really be used, and so the update will fail with invalid server name.
Maybe I would have to change the description a bit.
Question is if the issue is related to my shared hosting somehow, or if someone else can replicate by using the update component and force ftp mode and then 1. use incorrect ftp access info, and 2. use correct ftp access info.
Updated testing instructions and patched update container for reproducing the error to latest staging, i.e. 3.6.0-dev, which has the new functionality for the update component from PR #9612.
@brianteeman I have updated the description to latest staging. Can you try to replicate the issue if you find time?
@brianteeman It seems in the issue tracker tha changed description is not visible yet, but on GitHub you can see it. Can you reset the "Information required" status because I answered your question before?
Status | Information Required | ⇒ | New |
Am closing this issue because many changes in staging since then, and because it seems that nobody can replicate the issue.
If I find time I can test ftp mode again and and open a new issue if I find something.
Status | New | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2016-07-31 16:34:54 |
Closed_By | ⇒ | richard67 |
This sounds exactly like the issue I had a while back when testing the http
transport PR from @rolandd