Upgrade StorageTrouble with PubMed
PubMed now uses some anti-scrapper / anti-DoS measures, and perhaps because of that Zotero Connector sometimes fails to use the standard PubMed translator fails. The connector falls back to the (PubMed) Web page's metadata, which is not nearly as good (eg, "Neves, João Sérgio" becomes "Js, Neves").
I don't know if there's anything to be done on the developers' end but, as user, when it happens, I grab the PMID from the URL or PubMed's Web page, and add the record to Zotero from the identifier.
Perhaps being logged in to PubMed would avoid all this trouble, but I haven't tested it yet.
I don't know if there's anything to be done on the developers' end but, as user, when it happens, I grab the PMID from the URL or PubMed's Web page, and add the record to Zotero from the identifier.
Perhaps being logged in to PubMed would avoid all this trouble, but I haven't tested it yet.
I was on my Android phone and was using the pathway from my browser's share command to Zotero (the Android application).
In both cases, a record was created with the URL and no other publication metadata. The title was recorded as
"Checking your browser - reCAPTCHA" (from PubMed)
"Just a moment..." (from JAMA Network)
I was logged in to PubMed at the time FWIW, and had already completed their captcha challenge at least once earlier today.
This pathway (mobile browser - share - Zotero) worked fine for some other journal websites today, and is really convenient on the phone. I did have a small hiccup when I tried it on an NEJM article that I was accessing via a proxied URL, but when I reloaded the article page without the proxy, that pathway worked smoothly to create a Zotero record with all the appropriate publication metadata.
Hope this extra info is relevant and useful.
When I loaded PubMed's page, it didn't require a CAPTCHA. But when I tried adding the item to Zotero, what was added was a webpage about solving the CAPTCHA.
D1827818351