Vanilla 1 is no longer supported or maintained. If you need a copy, you can get it here.
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.

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

  • lechlech Chicagoland
    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.
  • lechlech Chicagoland
    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?
  • lechlech Chicagoland
    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?
  • lechlech Chicagoland
    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.