Can't save item from ScienceDirect

  • We'd have to see a Debug ID for loading of the page, not saving.
  • debug ID for loading a page
  • edited January 9, 2012
    This is the (abridged) URL that Zotero is trying to use (with the DOI translator): [...]

    Just to confirm, in the address bar you see direct ScienceDirect URLs? The main article URL doesn't appear at all in the debug output you submitted. (If it did, Zotero would use that, since it has a higher priority than DOI.)

    Also, that URL above appears to have something to do with Refinder service—is that something you've explicitly enabled?
  • @adamsmith: Thanks, the updated translator worked for me. (Tried it in standalone.)
  • On the Guest-Mode issue, it would be great is someone else could take a look. Obviously we can disable this again, but if it works for a lot of people that'd be too bad. Right now we're still getting a lot of errors on sciencedirect, so that's not good.
  • It works for me in guest mode in Scaffold, but not when I save manually-- I get the same behavior as Dan. There's some JavaScript that's inserting an IFRAME from that URL, but I don't see why Zotero can't be made to ignore it. I tried excluding it in detectWeb, but Zotero doesn't seem to be running detect on the original, but just on the iframe. Something's fishy here.
  • Hi,

    I'm still having problems saving items from SD.
    I submitted an error report, ID: 817236697

    I'm on campus so I'm logged in. I also tried logging in, but no luck either.

    Just to recap, I updated the translator yesterday and I do see Sciencedirect when I hover over the URL icon.

    Let me know if you need anything else
    Much thanks,
  • I am logged in, translators are reset and updated, ScienceDirect appears when I hover over the URL icon, and it doesn't work for me.
    Example URLs that are not working:

    Should I submit an error report?
  • edited January 10, 2012
    ajlyon: the translator isn't being run on the main page because another translator is found for the iframe. Even if ScienceDirect is disabled, the DOI translator will translate the iframe, which is not good. I will fix this in the browser code, but maybe it's worth adding a special exemption to the DOI translator for now? We could also make the ScienceDirect translator use to get the top window even if run in a frame (assuming no cross-domain issues).
  • I don't like adding hacks to general-purpose translators like DOI, so I'll see about using in the main SD translator.

    mark: Please do submit an error report if things are not working when you are not in guest mode.
  • simon: It would be nice if the main frame were tested before its iframes, as a general rule.
  • I don't think it would matter, since the detection is supposed to run on all frames and then use priority.
  • In that case something is wrong already-- DOI has a lower priority than ScienceDirect, so the iframe shouldn't be the one being parsed.
  • I see Simon has dealt with this already for trunk/3.0:

    I'll proceed with a hack to DOI, then, so we can fix this quickly.
  • In that case something is wrong already-- DOI has a lower priority than ScienceDirect, so the iframe shouldn't be the one being parsed
    The issue Simon fixed was that once it found one it wasn't continuing on. But they're still all supposed to be run, so the order doesn't matter.
  • Should be fixed now. Update translators and detection should give correct results in guest mode. It may be necessary to restart Firefox, since the DOI translator is cached on startup, I believe.
  • Hello, I have been following this thread for a couple of days and must admit that I don't understand all of what has been said. I have the same problem as was initially specified: I cannot save to Zotero from ScienceDirect by clicking on the "page" icon in the awesome bar of firefox (version 9.0.1). I take it that the "page" icon is what is referred to as the "zotero" icon. When I hover over this, I see the text "Save to Zotero (ScienceDirect)". However, when I click on the icon, I get a little box on the bottom right of my frame saying in part "Could not save item. An error occurred while saving this item ....". I recently (about 10 minutes ago) updated the translators from the preference frame of zotero and restarted firefox. This made no difference. The url of the file I am trying to save is

    I know that there is a library proxy in this url, but I have no trouble saving files from wiley with the same type of url.

    I hope this makes sense. I'm not sure if I am missing something or not.

    Thanks, Peter.
  • prjohnston: Provide a Report ID after trying to save.
  • hi,
    i was describing problems with sciencedirect a few posts up.
    Apparently my debug code showed the url i was trying to save as:

    that is definately not what i see in the address bar. I have all proxies disabled (including in zotero).

    I had never heard of 'refinder' but looking in my account details in sciencedirect I can see this is an application that has been enabled by my institution. I am not able to remove it. Is there something else I can try?
  • Further to previous comment, the report ID is 1706362538.

    Thank you.
  • edited January 10, 2012
    vpolito: Don't worry about it. Your problem is related to the general issue that was fixed above by Simon for the next release of Zotero. We're working on an interim fix.

    prjohnston: Thanks.

    ajlyon: Zotero is still trying to save the wrong iframe. The advertising frame needs to be blacklisted from the SD translator, not the DOI one—sorry if I wasn't clear. vpolito's "shindig" URL is what's being used by the DOI translator (due to the frames bug that Simon has fixed).
  • also @prjohnston - some of what's being written here is between people trying to fix the issue, so don't worry if you can't follow everything.
  • I just pushed another version that should finally get this working. And it works for me here, testing with standard Zotero in SD's guest mode.
  • I just updated zotero and it WORKS!!!!
    Many thanks guys for all the work and help!
  • Works for me now too.

  • Ummm... sorry to be the bearer of bad news but this still isn't working for me. I connect through EZProxy (managed by Zotero) and Zotero tries to use the DOI translator on ScienceDirect pages, which fails:

    Example URL:

    Error report: 2093980715 (although it doesn't seem to contain any Zotero errors, even though it was submitted immediately after triggering a failed item addition).

    Details: Zotero 3.0b3 for Firefox on OSX 10.6

    If this is fixed in the next release don't worry about it - the workarounds are relatively painless. Let me know if you need any further information or if I can help you with any (non-coding) troubleshooting steps.
  • works for me. Could you turn off proxy redirection temporarily in Zotero (preferences --> proxy), then reload the URL of the page without the proxy, i.e.
    and see if the Zotero translator detects that?
  • Bionatsci: You can install the 3.0 Branch dev XPI over 3.0b3 to check if it's fixed and then reinstall 3.0b3 afterwards. It easily could be from the issue that was fixed, if the DOI translator is triggering on an advertising frame or that Refinder gadget or the like. Short of your trying with the dev build, we'd know based on a Debug ID for the page load.
  • @adamsmith - the translator works fine without proxy redirection

    @Dan - debug output is here: D382799133 I had a quick look at the output and it does indeed seem to be picking up an advertisement frame - I didn't realise that this was only fixed in the dev XPI, and not in a translator update. I'll pass on installing the dev XPI for now as I'm about 80% of the way through a reasonably large project with Zotero and I don't want to risk breaking anything. If it would still be useful I'd be happy to install the dev version after my manuscript is submitted on the 24th January. I'm quite happy to work around this for now (Zotero has so many good ways to grab metadata these days that one way breaking almost never presents a major problem).

    Thanks for your help.
  • I didn't realise that this was only fixed in the dev XPI, and not in a translator update.
    ajlyon put a workaround in the DOI translator, but it would apply only to the main SD domain, not a proxied domain.

    The proper fix is in the dev XPI.
Sign In or Register to comment.