Extension reverting to preprint

Hello. I’ve noticed today on different publishing sites (Oxford and Wiley at least) when trying to import a published paper that the importer extension button reverts to the preprint version on bioRxiv. In each case, I previously had downloaded a preprint version, but had deleted it from my library before trying to import the new, published version. I also noticed that when reloading the page, if I quickly push the importer button, I see it initially recognize the correct journal, but then it switches to the bioRxiv preprint version. Can you please help get this fixed? Thanks in advance.

1 Like

Thanks for your report, @Cameron_Thrash. It is possible that the articles you are trying to access are behind a paywall and Paperpile doesn’t have access to them. For example, Wiley has a “Free to Read” designation for articles that allow users to read article PDFs, without the ability to download the article. This allows users to read the PDF but Paperpile can’t save the PDF to your library because access is restricted. In that case, Paperpile will attempt to get the PDF from elsewhere, like a preprint archive. Do you think that this could be the case for you? But let me know if you are observing something different and share example URLs so that the team can investigate.

Thanks Suzanne. This wasn’t for downloading PDFs, but simply for importing the reference.

@Cameron_Thrash Thanks for clarifying that the issue is with saving the correct reference metadata to your library, rather than saving the PDF of the reference.

Can you share an example URL where on reloading the page, the P button recognizes the correct journal but then switches to the bioRxiv metadata?

Alternatively, you can share a screen recording of the issue here, via the in app messenger, or emailing support@paperpile.com.

Hi Suzanne,
There are two pages where I noticed this behavior. However, as of today, the problem isn’t happening anymore, so perhaps it just needed more time? I’ve included the URLs below just in case that’s helpful. I had to add a space after the https so they would be accepted by the webform entry box. But I think we can close this issue. Thank you for your response!

“https ://doi.org/10.1111/gbi.12600”
“https ://doi.org/10.1093/bioinformatics/btae311”

1 Like

I just had it happen again, this time at Nature Communications. Here is the link and a screenshot:

https://www.nature.com/articles/s41467-024-48236-x

Thank you for sharing the screenshot and URL where this occurs @Cameron_Thrash; I have let the team know.

I found another one today. Screenshot attached.

Thank you for sharing @Cameron_Thrash. The team has been able to reproduce the issue and a fix will be part of the next release of the extension.

1 Like

Great! Glad to hear it.

1 Like