I disagree with removing the automatic disabling of updateservers as I think it's actually a useful feature by itself. Especially for updateservers which are not set up correctly.
If you don't do that, the update just takes ages and you have to manually find and disable the correct server.

The other points I agree with.

Just a thought: Instead of creating yet another method to enable an updateserver, would it make sense to use the one from the updatemodel? See https://github.com/joomla/joomla-cms/blob/staging/administrator/components/com_installer/models/update.php#L205
Currently, that one does enable all updatesites, but it would be easy to add a parameter which allows to enable a site by id, eid or name or whatever.
Or even better use the updatesites model: https://github.com/joomla/joomla-cms/blob/staging/administrator/components/com_installer/models/updatesites.php#L90

@test Successful (for all proposed tests). Thank you, Roberto!

@bakual We could always follow the disable-fetch-enable method I proposed in gh-5284. I know for a fact it works and does prevent the problem you describe. It just takes two small tweaks in the two JUpdater adapters.

I probably don't understand the disable-fetch-enable method. What is the point if you disable the server when you are still trying to access it? Imho if it's disabled, it should not be contacted at all like it is today. But I most likely misunderstood something.

Yes, you missed the point :)

We are inside a JUpdater adapter, let's say JUpdaterExtension, line 214. What I propose is this:
1. Disable the update site
2. Execute the try-catch block which fetches the update
3. Re-enable the update site

Why?

Currently the try-catch block will run to completion ONLY if the server responds within a "reasonable" amount of time, where "reasonable" is anything less than the PHP maximum execution time limit. What happens if the server takes 180 seconds to respond but the PHP maximum execution time limit is 10 seconds? We get a white page and the update site IS NOT disabled. Therefore any future fetch update attempt will lead to a white page again. Perceived state by the user: Joomla! is broken.

With my proposed trick you still get the white page the first time. BUT! The update site is now disabled, because step 3 (re-enabling it) did not run. Therefore the next time you try fetching updates will work, since the faulty update site is now disabled. Perceived state by the user: temporary fluke, Joomla! rocks.

Now, should you disable the update site when $response is null? No. According to my (and every other developer's) experience the null response is returned when there is a temporary network issue, a server misconfiguration or a server firewall preventing $http->get($url) from connecting to the update site. As a result $http->get($url) returns an immediate null reply. There is nothing appearing to be stuck as far as the user is concerned and we do give them feedback that this update site cannot be fetched from the server. This is an indication to the user that they have to contact their host to fix update fetching in Joomla!.

If we disable the update sites automatically we do a double disservice to the user:
1. Repeating the update fetch no longer returns any warnings and the user is not aware that all of his update sites have been disabled.
2. Even if the error condition is lifted, repeating the update fetch returns no feedback, misleading the user to thinking that their Joomla! installation and their extensions are up-to-date.

If we don't disable the update sites automatically we do a double great service to the user:
1. Repeating the update fetch returns the same error which they can paste to the Joomla! forum where someone more experienced will tell them what to do (basically, contact their host)
2. When they lift the error condition and retry fetching the updates they will KNOW that the result (updates available or no updates exist) is the CORRECT status, therefore they can trust the updater to tell them if their site is out of date or not.

I hope this sheds more light into the idea of disable-fetch-enable and why it actually fixes the problems we currently have. As I said, it is a well-tested solution.

Ah gotcha! Thanks for the explanation, it makes sense now!

You're welcome!

@test
This PR works fine here.

@nikosdion
Do we need anything else?

Not in this PR. I guess that after it's merged I can start working on the disable-fetch-enable implementation.

Let's go for it. :)

I submitted PR gh-5319 with the implementation of the disable-fetch-update and some improvements which can help web site owners to troubleshoot update issues.

Great job, thanks already!

Always a pleasure :)