Fix update check (change link to open download in NEW window to prevent repeated checks)

TomTesterTomTester New
edited January 2008 in Vanilla 1.0 Help
A little pet peeve... Whenever I check for updates and more than one is found, I invariably make the 'mistake' of clicking the download link. Since that link does not default to a NEW window (target="_new"), the add-on download will start in the current window (tab) and replaces the results of the update check, requiring ANOTHER update check to see which add-ons have been changed when I hit the back button. How about changing those 'download' links to NEW windows. TT

Comments

  • Middle, right or ctrl click then to open those links in new tabs then :) as target="_new" is absolutely nasty and deprecated in XHTML. However I can see your annoyance with having to restart the update check over in order to complete this.
  • Maybe a better solution would be to cache the update check results in an array for, say, the same time as Vanilla's update checks?

    Of course, you can always manually override.
  • Yeah, I was thinking the same thing when I originally replied but had no way to offer a proper solution so didn't mention it. I don't think it would be necessary to over-ride as it would most likely inherit it's preference from the update setting. But it could be convenient to carry it out in the following manner:

    Check for updates -> List Add-ons -> Run through the updates -> Store the update results within an array either within the conf/settings.php as a large serialized array or within it's own file with update paths included.

    So the next time a user goes back to the update page, instead of re-running the update it pulls from the cache first, if the user is convinced that the cache is outdated they could just simply force an update to rebuild the cache.
  • Lech, I know how to do it, just always forget... so then I curse vanilla (which doesn't deserve to be cursed, poor little vanilla) Re: storing last check results, how 'bout a local cookie... is the simplest solution, not?
  • With cookies you're limiting to how much data you can store providing you have dozens of add-ons installed. What I was suggesting above was to simply store the results of the update check into a file. So that way if you do happen to accidentally navigate away then back to the page the update check looks at the stored file before re-running the full check and displays the results.

    Obviously this would need to be done via a new add-on, heavy tweaking of the templates or a core change.
  • I'll settle for a cookie. Even with dozens of add-ons, how many bits would you need?
  • Enough bits to first tell the updater to not perform the update, and enough bits to tell it to tell you which add-ons are out-dated along with the links to each of those add-ons. Browsers will typically reject cookies if they exceed a certain size/length when created via header responses, I think the limit is something like 4kb.

    However, doing it via cookies might be a bad idea as that's bound to create problems from browser to browser and god knows what else. And is why I suggested the server-side caching, that way you could more accurately just over-ride the script in progress and pop the results from a cache rather than depending on the client. A cookie setting though might be best used to simply say "yeah, skip to the cache" though...
  • sorry to bring this post 'back to life', but I would love this functionality! can anyone build an addon that does precisely what lech suggested?
This discussion has been closed.