Comprehensive Zotero Plugin

Did anyone get {file++} links to work on windows? I added {file++} to my template, but something goes wrong with the translation from a relative to an absolute path. Logseq expands..\\zotero\\storage as /assets/zotero/storage and ignores the ...

The {file++} link contains a relative path (relative to the Logseq directory, looks ok): file://..\\zotero\\storage
when I click on the link, I get an error message Missing PDF "file:///C:/Users/path/to/logseq/assets/zotero/storage\\PIU7QTAR\\Xu_Song_2010_Some Test Document.pdf". Is this the correct path?

I am using this template

- citationFull
  template:: citeationInline
  template-including-parent:: false
	- alias:: {author lastname} ({year}) {title}
	  tags:: [[publication]], [[Logseq citation manager]],
	  type:: {type};
	  status:: 
	  icon:: šŸ“š
		- *{title}*. {publisher}.
			- {author}, {year}.
		- Abstract:
			- {abstract}
		- {file++}
		- Notes
			-

I am so glad about the burst of activity here, thanks @Aryan for another great plugin and everyone else here for a great ongoing discussion!

@andupaz I agree with gax points about the many further use cases a zotero API would enable

For @Aryan and @gax I would add one that is important for usability when citing from zotero in logseq:

the plugin does not enable the selection from specific zotero libraries and collections - but these are key organising principles both for individual work (eg a separate collection for paper y, project x, PhD z) as well as Group work (shared libraries with group A and B, each of which can again contain collections). Implementing this would go a long way to reedy the usability issues with citation selection mentioned above.

I am sure this is because the data is missing in the bibtex file - if it is, I am happy to bring this up with the bibtex plugin dev. Having this implemented would make the zotero plugin a solution for many zotero and logseq users

2 Likes

Thanks for clearing my doubts! I sure hope to see anything soon. With Aryans citation plugin now adding the PDF, Iā€™ll be switching to it. But depending on when the comprehensive plugin will be released, Iā€™ll have to rethink it. Lot of going back and forth.

@gax Yeah, I was able to link it in Windows. Put the {file++} in a new normal block by itself (not in properties).

Iā€™ve just pushed a major performance improvement and fixed an issue with the reindex on startup feature. Iā€™ll be adding support for a JSON format soon so that you wonā€™t have to deal with this indexing process for larger graphs.

3 Likes

Each search should now take under a second in the latest version.

@andupaz I tried putting the {file++} into a block by itself, but still the same problem.
The link inserted by {file++} is relative file://..\\zotero\\storage, but the error message shows an absolute path that ignores the .., it tries to find the pdf in logseq/assets/zotero/storage

- citationFull
  template:: citeationInline
  template-including-parent:: false
	- alias:: {author lastname} ({year}) {title}
	  tags:: [[publication]], [[Logseq citation manager]],
	  type:: {type};
	  status:: 
	  icon:: šŸ“š
		- *{title}*. {publisher}.
			- {author}, {year}.
		- Abstract:
			- {abstract}
		- Notes
	- {file++}
		-

Could you share your template?

@menelic could this be related to this Link to external pdfs in local Zotero folder and Better BibTex support issue?

I donā€™t think Iā€™ve added support for relative links yet. Not sure how to get them in my zotero instance.

From the discord:

You can build a link to the Zotero item using the following expression in the pdf link template [{citekey}](zotero://select/items/@{citekey})

1 Like

My template is

alias:: {author lastname}
- {file++}  
- #library  
- {title}  
	- {author}, {year}.  
- Abstract:  
	- {abstract}  

The only instance when I got the Missing PDF error was when it had two file paths within the parenthesis. Try changing the position and indentation of the block. It looks like yours is a child block from citationFull.

1 Like

I took a couple screenshots to show what is going on.
@Aryanā€™s plugin correctly inserts a relative path. The item has 3 attachments and they all end up in one link, instead as 3 links, but that is no big deal, I can just delete the two extra ones manually.

I deleted the two extra attachments, icon is now shown properly, but when I click on the link, the pdf doesnā€™t open in Logseq, and instead I get an error message with the wrong path under assets.

As far as I understand this, the citation plugin is working fine, the problem is Logseq interpreting the relative path as an absolute path inside of assets.

Here is my full template without the citationFull parent item:

Try remove file:// from the pdf template maybe?

when I remove file:// from the item note itself (path starting with .., I get exactly the same error message. I didnā€™t try ā€œTemplate for file URLs in yourā€ in your settings, just edited the file directly.

Pdf opens correctly in Logseq when I manually prepend the absolute path, i.e. file://C:\\Users\\....
You mentioned you didnā€™t add support for relative links, but on my system (Win 10), the plugin adds relative links (which is what it should do).

When I put in an absolute path without the file://, the Pdf opens in Acroread externally.

Strange. Might it be possible that your filepath is too long or that you have duplicate items in Zotero?

I donā€™t think so, the total absolute path length is about 100 characters, including the file://. Iā€™ve already spent a couple of hours trying out all combinations of different paths.

Logseq does not seem to process the relative paths correctly and always assumes they are under assets. Here is someone who has a similar issue:

Does Aryanā€™s plugin insert full or relative paths on your system?

I have absolute paths automatically inserted into mine.

interesting! I get relative paths, and those seem not to work (bug in Logseq), as discussed in another thread: Link to external pdfs in local Zotero folder and Better BibTex support

I guess I could automatically resolve the file paths into an absolute path. WOnā€™t work cross platform though. Else, you should post this bug onto githhub, seems pretty serious.

Hi Aryan, I donā€™t think there is anything wrong with your plugin. A relative path is clearly the better solution, otherwise the whole library will break if one uses a different path.
It looks like a bug in Logseq to me.

Actually. I think relative path is wrong. If your zotero folder was stored in the same location as the assets folder or the pages folder then it would be correct. But in this case itā€™s wrong as ā€¦/ in logseq will check for files in your db folder.
itā€™s

I just checked the paths in my .bib file. It has file paths relative to the folder of the bib file. This might be as I set a custom storage location in Zotero, maybe that is why andupaz has absolute paths.

That folder was at the same level as the top level logseq folder, so the paths would be correct as seen from this folder.

As an experiment, I exported into the assets folder, which gives relative paths starting with ../../. Logseq ignores these relative path and puts everything under assets, so it looks for logseq/assets/zotero/storage. This looks like a bug. Once this works, I think it would make sense to accept relative paths in the .bib file, but as this file might not reside in the assets folder, the paths need to be replaced by a relative path with respect to the Logseq folders.

The relative path issue is indeed a known bug, here is an older feature request: Relative path for Zotero data directory