@milux In a moment I'll be testing this PR.
cc @trzepiz @ot2sen @noras666 @brianteeman Please test this.

I have tested this item ✅ successfully on 613a6c1


OS Windows 8.1

#Fields: datetime   priority clientip   category    message
2016-11-07T16:11:17+00:00   INFO ::1    update  Update started by user Super User (410). Old version is 3.6.2.
2016-11-07T16:11:20+00:00   INFO ::1    update  Downloading update file from http://joomla-official-downloads.s3.amazonaws.com/joomladownloads/joomla3/Joomla_3.6.4-Stable-Update_Package.zip?[AWS patams].
2016-11-07T16:11:25+00:00   INFO ::1    update  File Joomla_3.6.4-Stable-Update_Package.zip successfully downloaded.
2016-11-07T16:11:27+00:00   INFO ::1    update  Starting installation of new version.
2016-11-07T16:11:49+00:00   INFO ::1    update  Finalising installation.
2016-11-07T16:11:49+00:00   INFO ::1    update  Ran query from file 3.6.3-2016-08-15. Query text: ALTER TABLE `#__newsfeeds` MODIFY `link` VARCHAR(2048) NOT NULL;.
2016-11-07T16:11:49+00:00   INFO ::1    update  Ran query from file 3.6.3-2016-08-16. Query text: INSERT INTO `#__postinstall_messages` (`extension_id`, `title_key`, `description.
2016-11-07T16:11:50+00:00   INFO ::1    update  Deleting removed files and folders.
2016-11-07T16:11:56+00:00   INFO ::1    update  Cleaning up after installation.
2016-11-07T16:11:56+00:00   INFO ::1    update  Update to version 3.6.4 is complete.

I have tested this item ✅ successfully on 613a6c1

Applied the patch using patchtester to the 3.6.2 that couldn´t be updated yesterday.
After applying patch and running the update it completes and is now at 3.6.4

RTC

Hmm i'm not sure here. @mbabker can you take a look here?

Waiting for review

@zero-24 The change could be problematic when the last observed location does not represent a file ending on ".zip". Is that possible? In that case I might check for proper file extension and append it manually if necessary...

Well there are two options:

1) Just remove the query string segment and leave it as the URL fragment without a file extension (probably bad news)
2) Follow the headers to get the correct file name with file extension.

I don't think there's an issue here honestly, unless someone's got a scenario I'm not aware of to look at.

Thanks @mbabker 👍

@mbabker
1) Already tried that one... doesn't work, Joomla doesn't extract the file without proper file extension.
2) Exactly what I did, however if the file from AWS doesn't end on ".zip", the process will fail

There are actually two more options:
3) Just remove the query string, check if the basename ends on ".zip", append if necessary
4) Resolve until destination and do the same thing as in 3)

So, what should it be? ;)

Leave it as is. I wouldn't hardcode a .zip suffix check in the off chance the file extension ever changes (like if we tried serving the smaller .tar.* files instead of the ZIP package).

Leave it as is. I wouldn't hardcode a .zip suffix check in the off chance the file extension ever changes (like if we tried serving the smaller .tar.* files instead of the ZIP package).

administrator/components/com_joomlaupdate/restore.php
method: getUnarchiver()

it only supports: JPA, JPS, ZIP

... with JPA and JPS being Akeeba-specific formats afaik, but how about a 5th solution:
5) We take the file extension from the original URL and append it to the basepath if it is not there yet. 😜

This is fine as is. Really we'd only have further problems if someone uploaded packages to AWS in the future without a file extension, in which case it'd probably be a broken file anyway. Plus our main interface to AWS is through the downloads site and is a Joomla extension, so the packages are going through validation on upload there. Let's roll with it.

@joomla/cms-maintainers When this is merged, I'd suggest tagging a standalone update for the update component since it looks like anyone hosting a production site on a Windows platform will have issues upgrading with packages pulled from AWS thanks to the URL query strings in both the XML update file and the resulting URL after following all redirects.

There is a rare problem (maybe not possible problem) that might occur with this PR

if the redirect/final URL does not have a query string (no character ?) then:

// Remove URL and query string
$urlBasename = basename($packageURL);
$basename    = substr($urlBasename, 0, strpos($urlBasename, '?'));

$basename will be empty, because substr will return an empty string, because strpos will give FALSE as length parameter

This should be safer :

// Remove URL and query string
$basename = basename($packageURL);
if (strpos($basename, '?'))
{
    $basename = substr($basename , 0, strpos($basename, '?'));
}

Please see my above comment

about adding zip as extension

• only in the case that extension is not detected in the redirected URL, is a good sanity check,

Also we can try to grab the extension for the original update URL too,
Besides that is the purpose of &jcompat=my.zip , right ?

Is it preferable if no extension is detected that upgrade will fail ?
Plus currently as mentioned above, the getUnarchiver() only supports ZIP and joomla will not distrubute packages with JPA or JPS format

@ggppdk Thanks for your suggestion, integrated that.
Because of what @mbabker suggested, I don't think that we need to hassle around with the extension any more.
Is this ready for RTC then?

Needs tests again and it seems that Travis is not happy

Exactly... I just wonder how I made it unhappy? 🤔

@jeckodevelopment Maybe now? 😉

test test test 😄
thanks!

I have tested this item ✅ successfully on 4c66273

I have tested this item ✅ successfully on 4c66273

@jeckodevelopment Done, for the sake of it. (There wasn't really a change, and yes, I actually tested it even though and didn't just press the submit test button. 😉 )

RTC

Is it planned a new version of the com_joomlaupdate component with this fix before the release of Joomla 3.7.0?

@wilsonge @rdeutz any plans on this here?

No. We only distribute com_joomlaupdate in exceptional circumstances - basically when we make break the updater in a release. All other modifications ship as per the usual release cycle of the CMS

@wilsonge Without this fix com_joomlaupdate does not work under Windows. See #12817 (comment) and joomla/joomla-websites#742

I would suggest someone publish a page with guidance for users on a Windows platform as they cannot direct download and upgrade if the decision is to not release an interim update for the component.

@mbabker This is a big global problem for all Windows users and Windows servers. Should I tell everyone in Poland that "One click update" does not work on Windows?.

It's fixed in the code for 3.7. I can't do anything about any other decisions.

How many people run Joomla on a windows server?

13% of sites sending stats in the last 60 days are Windows. How many of those are local dev versus production, we don't track, but that's definitely a higher use rate than other configurations we support.

13% ? wow... would be interested to find out how many were IIS and how many were XAMP - maybe the stats should log server type too ?