Zotero file location in config.edn does not work between platforms

[ianhellstrom]

Search first

• I searched and no similar issues were found

What Happened?

I use Logseq on MacOS and Ubuntu with the Zotero integration. Since everything except the API key is stored in config.edn and config.edn is also synced (through git), the problem is that the file locations on both systems are not identical, i.e. if I updated the right location on my Linux machine and sync all files (incl. config.edn), then it won't work on my Mac. If, on the other hand, I use the Mac file locations, I cannot open PDFs from Zotero on my Linux box.

It would be great if config.edn did not store the file location, or made it optional, in which case it (like the API key) has to be provided on each machine.

What is more, the page edn files are also updated whenever you open such a PDF, because the paths are different and part of the Markdown.

Reproduce the Bug

1. Set up Logseq with Zotero on Mac
2. Set the file location to Zotero's default: https://www.zotero.org/support/zotero_data
3. Set up Logseq with Zotero on Linux
4. Set up the file location as per Zotero's setup on Linux
5. Sync to git from either Mac or Linux
6. git pull to the other machine
7. See that the PDF does not open because the paths are different

Expected Behavior

Zotero paths unique to each machine, so that:

• You can open files independently from how they are stored locally
• File paths are not hard-coded in the edn files of the pages

Screenshots

No response

Desktop or Mobile Platform Information

Ubuntu 20.04, Logseq 0.9.4
MacOS 10.15, same Logseq version

Additional Context

No response

Are you willing to submit a PR? If you know how to fix the bug.

• I'm willing to submit a PR (Thank you!)

[hairuo]

I have the same problem between two pc, both are Windows 10 and Logseq 0.9.1:

Reproduce the Bug

After set up Zotero API key and etc.

1. On computer A, Windows 10, username "Atom":

   Open and set:

   Logseq -> Settings -> Features -> Zotero Settings:

   Zotero linked attachment base directory: C:/Users/Atom/OneDrive/Zotero_Zotfile

   Zotero data directory: C:/Users/Atom/Zotero

   Sync everything.

2. On computer B, Windows 10, username "Bell":

   Open and set:

   Logseq -> Settings -> Features -> Zotero Settings:

   Zotero linked attachment base directory: C:/Users/Bell/OneDrive/Zotero_Zotfile

   Zotero data directory: C:/Users/Bell/Zotero

   Sync everything.

3. Back to computer A, open Logseq, and found problem:

   Logseq -> Settings -> Features -> Zotero Settings:

   Zotero linked attachment base directory: C:/Users/Bell/OneDrive/Zotero_Zotfile

   Zotero data directory: C:/Users/Bell/Zotero

   All the username "Atom" here changed to "Bell" so that I can't open PDF of Zotero in Logseq.

[cnrpman]

Sounds need some extra design on the cross-device config file
I wonder if the global config could partially solve the issue https://docs.logseq.com/#/page/global%20config.edn

[hairuo]

Sounds need some extra design on the cross-device config file I wonder if the global config could partially solve the issue https://docs.logseq.com/#/page/global%20config.edn

Sounds need some extra design on the cross-device config file I wonder if the global config could partially solve the issue https://docs.logseq.com/#/page/global%20config.edn

Hello, thanks for your reply. As your link provided says: Any options that are valid in the local config.edn are valid for global config.edn.

It seems I can't modify global config.edn independently. I tried to cut all content from local to global, then global config.edn will have no content either after a while. Any modification in local config.edn seems determin global config.edn.

It is also mentioned "Local config.edn overrides config options that are present in a global config.edn. However, if the config is a map, the local config option is merged over the global config option." Where I don't quite understand how the example helps in this case.

[Feliconut]

My current workaround is

1. backup the config.edn and delete it from the graph
2. add logseq/config.edn to .gitignore
3. commit and push
4. put the config.edn back

Then everytime you clone the repo to somewhere else, a new config.edn will be generated for that specific repo.

[hairuo]

Thanks for the reply. This is really a good solution if using GitHub to sync everything.

Meanwhile, I hope Logseq could also find a way to solve this sync problem with storage sync services.

[cnrpman]

Maybe we have to wait for a "device specific" config mechanism. It won't be a small project.
Design & code contribution is welcome. I'm happy to review any PR on this.

[e-zz]

Maybe we have to wait for a "device specific" config mechanism. It won't be a small project. Design & code contribution is welcome. I'm happy to review any PR on this.

It looks to me close to what the profile option does. As docummented here it is dedicated to configuring zotero “device specifically". It is a bit buggy, lacking a clear guide for users in documentation. So I struggled a bit but in the end it worked.

---

Here is how I did it.

1. In logseq config, create a new zetoro profile on one device, including api key and zotero paths
2. Use /zotero command in logseq to check everything is working
3. Sync the confg to the second device
4. Repeat step 1 and 2 on another device
5. Sync the config back to the first device

Now in theory it is good to go. Unfortunately, as I said, it's a bit buggy so this is not the end.

1. When we work on a diffferent device, logseq might still crash due to a wrong "profile". The solution is

   • Go to settings-> features -> zotero
   • select the correct profile for your device, one should be able to open pdfs smoothly.

2. Even after this, those annotation blocks from another device are still not functioning (And DON'T CLICK them. Logseq will crash) . The solution is to go to @<PDF_name> page. Open your pdf from there, then

   • make any new annotation,
   • or, just right click on any annotation -> Linked references

This works until we do similar things on anothe device (and sync). So it's just a temporary solution.

@cnrpman Would there be any improvement to the profile function of logseq? It's not seamless. I really hope logseq could figure out which profile to use by itself and avoid the steps I've shown here. I could open another feature request issue about this if necessary. Thanks !

---

Update: This PR #10430 might solve the problem. It works quite well for me in the last few months, both on win10 and Ubuntu22.04. If you are interested, I release the solution on this fork. And please backup your data first if you would like to have a try!