User tests: Successful: Unsuccessful:
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.
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.
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:
max_execution_time=5
in your php.ini (regular values: 60 to 120)Timeout = 5
(regular values: 120 to 300)http://www.deelay.me/29999/http://update.joomla.org/core/list.xml
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
This PR is fully backwards compatible
Two translation strings are added in en-GB.plg_system_debug.ini. The necessary time for translation is approximately 2 minutes.
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.
Labels |
Added:
?
|
@infograf768 gh-5320 is unrelated to this PR.
Category | ⇒ | Updating |
#5319 (comment)
I know...
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
Easy | No | ⇒ | Yes |
@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.
Merged.
Status | Pending | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2014-12-27 16:37:15 |
@nikosdion
could you look at this?
#5320