? Success

User tests: Successful: Unsuccessful:

avatar nikosdion
nikosdion
4 Dec 2014

Executive summary

After PR gh-5296 Joomla! will not disable update sites when they cannot be read from. If an update site takes forever to load (much longer than the PHP and web server timeout) trying to fetch updates will result in blank pages or other web server error pages. This will mislead the user into believing that Joomla! is broken. This PR addresses this issue on subsequent attempts to load the update information.

Technical information

This PR aleviates this issue by using the disable-fetch-enable strategy. The update site is diabled before trying to fetch its contents and enabled afterwards. If PHP dies before fetching the contents the update site will remain disabled, therefore future attempts to fetch updates will success.

Since I was at this, I did a minor refactoring of the JUpdater adapters to make them a little bit more DRY.

This PR also adds a Log Everything option to the System - Debug plugin which allows site administrators to see the log messages produced by Joomla!, including the JUpdater library. These messages allow them to see which update sites take a long time to load or fail to load at all.

How to test

We can only test that this PR doesn't break anything. Try installing out of date extensions and the apply this PR. Fetch the updates. You should see that the udpates are visible, just like before applying this PR.

Moreover, go to Global Configuration and set Debug Site to Yes. Enable the System - Debug plugin. In the plugin's Options set Log Everything to Yes. Go back to the update page, Purge then Fetch. Now look into your site's logs folder, there's a file named everything.php. Open it with a text editor. You will see how long it took to fetch the contents of each update site.

Important note: most people cannot test the automatic disable of faulty update sites because it requires a broken update server and a broken web server :D If you are technically proficient you can create the 'perfect storm' setup by following these steps:

  • Set max_execution_time=5 in your php.ini (regular values: 60 to 120)
  • Edit your Apache configuration and set Timeout = 5 (regular values: 120 to 300)
  • RESTART APACHE
  • Go to Joomla! Update, Options and set "Update server" to "Custom URL" and the Custom URL below to http://www.deelay.me/29999/http://update.joomla.org/core/list.xml
  • Go to Extensions, Extensions Manager, Updates and try fetching the updates. You'll get a timeout in about 5 seconds.
  • Check the Update Sites. The Joomla Core update site is now disabled.
  • Go to Joomla! Update, Options and set "Update server" to "Current Minor & Patch Releases"
  • Check the Update Sites. The Joomla Core update site is enabled. If not, enable it (and let me know if that happens).
  • Go to Extensions, Extensions Manager, Updates and try fetching the updates. The updates now work.
  • Check the Update Sites. The Joomla Core update site is still enabled.
  • REMEMBER TO REVERT YOUR php.ini AND APACHE CHANGES!

Without the patch the update site is never disabled.

Pro tip: if you want to test what happens with major delays to HTTP requests take a look at http://www.deelay.me It can be even installed locally. It comes in handy for testing against edge conditions like this one

Backwards compatibility

This PR is fully backwards compatible

Translation impact

Two translation strings are added in en-GB.plg_system_debug.ini. The necessary time for translation is approximately 2 minutes.

Documentation impact

You may need to document the new Log Everything option under System - Debug. I think the pop-over description is more than sufficient.

Moreover, you need to document the way to troubleshoot update fetch taking too long. Here's a (very) draft version.

Q: What can I do if finding updates takes too long?

A: You can see which update sites cause a big load delay. First go to Global Configuration and set Debug Site to Yes. Then go to Extensions, Plugin Manager and find the System - Debug plugin. Click on it. In the Logging tab set Log Everything to Yes, then click on Save & Close. Go to Extensions, Extension Manager, Update and click on the Purge button, then click on the Find Updates button. Connect to your site via FTP or your hosting control panel's file manager. Navigate into the logs directory. There is a file called everything.php. Open it with a text editor. You will see log messages showing how long it takes for each update site to load. Typical load times should be less than 2 seconds. If you see an update site take an extreme amount of time it is the cause of the delays in finding updates. You may want to disable it from Extensions, Manage Extensions, Update Sites but keep in mind that you will not be receiving update notifications for the extension(s) linked to this update site.

avatar nikosdion nikosdion - open - 4 Dec 2014
avatar jissues-bot jissues-bot - change - 4 Dec 2014
Labels Added: ?
avatar infograf768
infograf768 - comment - 4 Dec 2014

@nikosdion
could you look at this?
#5320

avatar nikosdion
nikosdion - comment - 4 Dec 2014

@infograf768 gh-5320 is unrelated to this PR.

avatar brianteeman brianteeman - change - 4 Dec 2014
Category Updating
avatar infograf768
infograf768 - comment - 5 Dec 2014

#5319 (comment)
I know...

avatar infograf768
infograf768 - comment - 5 Dec 2014

Can you make Travis happy? (and ping me on skype)
FILE: ...avis/build/joomla/joomla-cms/libraries/joomla/updater/updateadapter.php


FOUND 4 ERROR(S) AND 1 WARNING(S) AFFECTING 5 LINE(S)


131 | ERROR | Missing @return tag in function comment

134 | ERROR | Cast statements must be followed by a single space; expected

| | "(int) $update_site_id" but found "(int)$update_site_id"

135 | ERROR | Cast statements must be followed by a single space; expected

| | "(bool) $enabled" but found "(bool)$enabled"

168 | ERROR | Cast statements must be followed by a single space; expected

| | "(int) $updateSiteId" but found "(int)$updateSiteId"

257 | WARNING | Line exceeds 150 characters; contains 172 characters

avatar infograf768
infograf768 - comment - 5 Dec 2014

@test

This works fine here

avatar zero-24 zero-24 - alter_testresult - 5 Dec 2014 - infograf768: Tested successfully
avatar zero-24 zero-24 - change - 5 Dec 2014
Easy No Yes
avatar wilsonge
wilsonge - comment - 26 Dec 2014

@test Partial success. Went through the detailed perfect storm setup. Everything worked as described but did have to manually enable the update site. So letting you know as requested Nic. This was on a XAMPP install on windows 8.1

avatar nikosdion
nikosdion - comment - 27 Dec 2014

@wilsonge Your test is successful. I wanted you to notify me about the update site not being enabled by com_joomlaupdate because it is a bug in com_joomlaupdate itself, unrelated to this patch. I was trying to "hijack" the testing of this PR to verify the existence of the com_joomlaupdate bug I thought I had discovered. Yeah, I know, sneaky me :p

I will come back with another PR for com_joomlaupdate. In the meantime you can set this PR (gh-5319) RTC as we have two successful tests.

avatar wilsonge
wilsonge - comment - 27 Dec 2014

Merged.

avatar wilsonge wilsonge - change - 27 Dec 2014
Status Pending Closed
Closed_Date 0000-00-00 00:00:00 2014-12-27 16:37:15
avatar wilsonge wilsonge - close - 27 Dec 2014

Add a Comment

Login with GitHub to post a comment