Support/Comments for extra "Updater"

Hey Bob,

yep, I try to be fast in that . And it affected my own installations, so the need for a solution was already there... And I really don't like to be somewhat responsible for people losing access to their sites - beta state or not.

No worries, the notifier does not check on every request. Instead it only checks the current timestamp towards the saved one from the last notification. Only if the configured time is over (say 24h) the next steps are done - if necessary. Remote checks for updates have their own cache partitions, so this does not happen very often. This ensures that response times shouldn't be affected (not measurable so far).

At first I did have the notification beeing triggered OnManagerLogin. But this is imho quite useless: if you login, you will (hopefully) see the widget showing the update information right after that. No need to send out an extra email notification then.
Instead, if you haven't visited your manager for a while, my approach ensures that you still get informed about updates. Even with very low traffic on a site at least the googlebot triggers the notification check from time to time.

But you are right, I might filter the notification check as well on special pages to keep the impact even lower. It must only be ensured that the plugin is called on a regular base with a time span less than the minimum configured notification time. Maybe the googlebot together with a "hidden" page can be exploitet a bit more for that .

Good point about OnManagerLogin. I like the googlebot idea.

I have the following issue with Updater at the moment: the first manager login after the cache is expired has a long delay on my installations. It would be better to have a deferred update check, and the delay for the whole dashboard page is away. Only the widget itself would wait for the data. This could be done with an ExtJS/AJAX connector/processor call.

I think the notifier should work the same: if the cache is expired, a asynchronous connector/processor call is rendered at the end of the frontend page. Otherwise TTFB is worse for less visited sites … This connector should be callable by CLI too to make a direct cronjob call possible.

Do you have a GitHub Repository for this?

I hadn't thought about OnWebPageComplete, which reportedly fires *after* the page has been sent off to the browser so it shouldn't slow down page loads at all.

Hey Jako and Bob,

thx for your hints. You are perfectly right with the long taking first login after cache expiration. I am aware of this, and asynchronous calls esp. for the widget are already on my list.

I neither thought about OnWebPageComplete, because I simply did not realize that it is fired after the whole page is sent to the browser. This would be perfect for my use case if it really works like we think it does. This way we wouldn't even need a connector call to be rendered into the page. I just have to change (again :-() the event to react on. If it does not impact page load any more, it would also be possible to decrease the cache expiration times for updater and for the notifications.

Btw: does anyone now how I can change the title of a thread in this forum? I would like to get rid of the 0.2.4 version in it...

And, unfortunately, currently there is no github repo for Updater. But I will set this up in the next days to streamline development and bug fixing.

Ok, just tested it with OnWebPageComplete (and a sleep(5)). Unfortunately it works not as good as expected: http transfer of the page does not stop, causing the browser to wait for anything else coming from the server (which does not happen). In the result, the DOM ready event in the browser is delayed, and this will cause a lot of front pages to display incorrectly (or with a flicker), if the time gap is too long.

OnWebPageComplete is called during _postProcess, so it is not running 'outside' of the http transfer.

It does not need a connector call on the frontend with this: https://segment.com/blog/how-to-make-async-requests-in-php/

Thanks Jako, did read the article. I think the socket solution will do it. The curl-exec seems dirty to me (and I am not sure if this works on all systems).

It gets all excited and warns me that my core needs to be updated, because I'm running a build of 2.4.0-dev.

The new version 0.2.10-beta should now detect dev builds. It then does not notify you any more about updates and the widget only shows an informational message (blue), instead of updates available (red) or everything fine (green).