Closed dstillman closed 7 years ago
(Which I suppose means this mostly belongs in zotero/zotero, but we can figure out a plan here.)
So with option 2, would there still be a way to install the connector without ZSA? (for users that want to use it with zotero.org directly) Would it have to involve some manual file copying? On Jul 21, 2015 4:32 AM, "Dan Stillman" notifications@github.com wrote:
(Which I suppose means this mostly belongs in zotero/zotero, but we can figure out a plan here.)
— Reply to this email directly or view it on GitHub https://github.com/zotero/zotero-connectors/issues/40#issuecomment-123237949 .
No copying. It'd still just be a download link — it wouldn't actually be bundled (because it's not even possible, or at least condoned, to side-load Safari extensions). Standalone would just send you to a download page.
If we kept a prominent download link on the main download page, I'm not sure how we'd avoid prompting unnecessarily if the user installed the Safari extension before first starting Standalone, though.
Personally, I think that riding on the official updating mechanism is the proper route. Granted that the prompt is quite verbose and perhaps somewhat confusing (the actual buttons are quite clear IMO), but Safari users may already be familiar with such prompts from other extensions they use.
Of course we need to account for user error, where the user chooses to install the extension "from developer" and would no longer receive updates. So in either case, we should implement an update check in ZSA, and compatibility check in both ZSA and connector (to prompt user to update or downgrade one of them if compatibiities don't match up).
Would it be possible for us to detect if the Safari extension is installed "from developer" and then keep an eye on extension updates from within Safari? (say, on Safari start-up)
Is there a bypass to make Zotero connector work for Safari 9?
We're not going to distribute via the gallery — it takes months for extensions to be approved, and we can just prompt to upgrade in the client if we get a ping from an outdated version.
I am still seeing problems with the Zotero extension in Safari not being updated – no notification or prompt anywhere. Might you reconsider making the extension available in the Extensions Gallery? My colleagues have versions of the extension on their machines that are many months old, so the reason given above of approvals taking awhile is moot.
Alternatively, given the improvements of Zotero 5, might it now be possible to distribute it through the Mac App Store and use the new mechanism for bundling the extension that way?
The Safari extension doesn't update automatically or prompt, but when there's an update you should see an Updates line at the bottom of the left column in the Extensions tab of the Safari preferences. That should currently show 5.0.25 if you have an earlier version.
We're still planning to prompt from the client if the Safari extension is out of date — that just hasn't happened yet. The Extensions Gallery is pretty close to abandoned, and distributing through the MAS is neither possible nor something we'd want to do.
In Safari 9 on El Capitan (and, apparently, a 10.10 dev beta, since I have it too), only Safari extensions distributed from the Safari Extensions Gallery will auto-update. We have to decide whether we want to submit the extension to the gallery or whether we want to handle updates through Standalone. If we do the latter, it'd need to be something like this:
1) We get the latest connector version either from the a hard-coded value in each release or from the daily repo update check (the same as we now do for the PDF tools). Latter might not be necessary, and it would only work if there aren't connector-compatibility-breaking changes between Standalone versions (or we did server-side user agent checking in the repo).
2) If the latest available version is later than a stored pref, or the pref value doesn't exist, we prompt the user to upgrade.
3) If they choose to upgrade, we send them to a download page, which would have to be Safari-specific so that it could show a warning if they weren't in Safari. Otherwise if someone had Chrome as the default browser they'd either 1) never get the upgrade if we updated the pref when the clicked to upgrade or 2) keep getting the prompt if we updated the pref only on the first request received from the connector. (Or maybe we can actually load a URL in Safari explicitly.)
While our usual download page would work, it'd be better to have something like 1Password's.
If we do want to update from the Safari Extensions Gallery, we should update as soon as possible, since anyone running a 10.10 or 10.11 dev or public beta will never get an update. The process for getting people on the gallery version is also unclear to me. When I try to update the 1Password extension manually, or if I uninstall and then install their previous 4.4.0 version, Safari prompts me to install either the developer version or the auto-updating gallery version, which seems awfully confusing:
So I'm inclined to just update through Standalone, particularly since version compatibility is probably an issue anyway.
This is also related to a mechanism for installing the connector at first run for all users. If we haven't either prompted for or seen either connector before, we should probably display an install prompt at startup. And in any case, we should include an "Install Browser Extensions…" menu option that opens the download page (as in 1Password).