default preferences in Zotero 7

[Dan Stillman]

It was mentioned in another thread that default preferences aren't read
when a bootstrapped plugin is installed or enabled.

We've addressed that in the latest dev build (with a new file location)
and added example code in Make It Red 1.2 for handling this in Zotero 6:

https://www.zotero.org/support/dev/zotero_7_for_developers#default_preferences

[David Hoff-Vanoni]

Thanks for this update, Dan.

For a fully-bootstrapped plugin (like Make It Red 1.2), I was wondering if we could avoid the duplicate `prefs.js` file by changing the file path in the `setDefaultPrefs` function in `bootstrap.js` from `defaults/preferences/prefs.js` to just `prefs.js` so that Zotero 6 could use the same file as Zotero 7. The idea would be to avoid the existing Zotero 6 default preferences loading functionality altogether and handle it all via the `setDefaultPrefs` function. I imagine the check of `reason` would need to be updated to include `APP_STARTUP`—or maybe the `reason` check could just be removed altogether?

Would this approach work, or am I missing something that would cause an issue?

[Dan Stillman]

On 1/19/23 1:28 AM, David Hoff-Vanoni wrote:
> For a fully-bootstrapped plugin (like Make It Red 1.2), I was
> wondering if we could avoid the duplicate `prefs.js` file by changing
> the file path in the `setDefaultPrefs` function in `bootstrap.js` from
> `defaults/preferences/prefs.js` to just `prefs.js` so that Zotero 6
> could use the same file as Zotero 7. The idea would be to avoid the
> existing Zotero 6 default preferences loading functionality altogether
> and handle it all via the `setDefaultPrefs` function. I imagine the
> check of `reason` would need to be updated to include `APP_STARTUP`—or
> maybe the `reason` check could just be removed altogether?
>
> Would this approach work, or am I missing something that would cause
> an issue?

Yes, you're totally right — that makes more sense. I've adjusted Make It
Red 1.2 to do that and updated the documenation section.

Thanks!

[Emiliano Heyns]

For now it's still defaults/preferences/defaults.js, with the usual "pref(...)" calls, right? In 6.0.20 my default prefs seem not to load; they're missing from the advanced view, and in my prefs UI menulists and textfields that should show the defaults are blank.

[Dan Stillman]

On 1/24/23 8:09 AM, Emiliano Heyns wrote:
> For now it's still defaults/preferences/defaults.js, with the usual
> "pref(...)" calls, right? In 6.0.20 my default prefs seem not to load;
> they're missing from the advanced view, and in my prefs UI menulists
> and textfields that should show the defaults are blank.

It's explained entirely in the documentation section I linked to:

https://www.zotero.org/support/dev/zotero_7_for_developers#default_preferences

[Emiliano Heyns]

Which is why I'm asking. BBT is still overlay, I have my defaults in defaults/preferences/defaults.js *and* prefs.js, and my defaults are not present after start. I have resorted to setting them explicitly at start by calling Zotero.Prefs.set for all of the ones that are undefined (which is all of them), but then they all show up as modified in the advanced UI.

[Dan Stillman]

On 1/26/23 2:30 AM, Emiliano Heyns wrote:

Which is why I'm asking. BBT is still overlay, I have my defaults in defaults/preferences/defaults.js *and* prefs.js, and my defaults are not present after start.

Not sure what to tell you. Make It Red 1.0 (overlay) and 1.1 (overlay + bootstrap) are both loading default prefs for me in 6.0.20, showing a default pref of extensions.make-it-red.intensity=100 and "Make It Red: Intensity is 100" in the debug output at startup.

I have resorted to setting them explicitly at start by calling Zotero.Prefs.set for all of the ones that are undefined (which is all of them), but then they all show up as modified in the advanced UI.

Well you wouldn't do that regardless. The linked documentation section explains how to set default prefs, which isn't the same as setting regular prefs.

[Emiliano Heyns]

I know I shouldn't have to do this, and it used to work previously, but just having pref(...) calls in defaults/preferences/defaults.js does not set the defaults for me. I don't see anything in the docs that would indicate I need to do more for an as of yet overlay, Z6-only plugin. I read

If your plugin will work in overlay mode in Zotero 6 and bootstrap mode in Zotero 7, create defaults/preferences/prefs.js and add a step to your build process to copy it to prefs.js in the plugin root. Zotero 7 will load both at startup, but as long as the contents are the same, there won't be any difference in the created preferences.

Which is exactly what I'm doing.

I don't know how to debug this.

[Dan Stillman]

On 1/26/23 2:55 AM, Emiliano Heyns wrote:
> I know I shouldn't have to do this, and it used to work previously,
> but just having pref(...) calls in defaults/preferences/defaults.js
> does not set the defaults for me. I don't see anything in the docs
> that would indicate I need to do more for an as of yet overlay,
> Z6-only plugin.

No, you're misunderstanding. What I'm saying is that even if you
couldn't get this to work and needed to set default prefs manually, you
wouldn't do it the way you described, using Zotero.Prefs.set(), which is
for normal prefs and has the problem you describe. You would do it the
way we've documented. The documentation links to precise example code
for setting default prefs manually, since that's necessary regardless in
Z6 bootstrap.

Beyond that, I can't tell you why defaults/preferences/defaults.js isn't
working, but you can start with the Make It Red example, confirm that it
works, and iterate from there to your current code to see if/when it
stops working.

[Emiliano Heyns]

You mean setDefaultPrefs? What should I pass as its rootURI? My chrome.manifest does not have the root mapped.

[Dan Stillman]

On 1/26/23 4:18 AM, Emiliano Heyns wrote:
> You mean setDefaultPrefs? What should I pass as its rootURI? My
> chrome.manifest does not have the root mapped.

It can be any chrome:// URI.

Again, though, defaults/preferences/*.js works in Make It Red 1.0, which
is an overlay extension, so if you want to figure out why the normal
mechanism isn't working properly for you, you should start with that.
I've tested with both a source build and an XPI on macOS.

[Emiliano Heyns]

The thing is I don't know how I would go about finding that out. It's not code that I used to load myself, the mere presence used to be enough for it to load, so I'm not sure what I even *could* do to influence the loading of it.

But I'm working towards restartless anyhow, so maybe the point is kind of moot. In the interim, setDefaultPrefs makes sure I have a known-good situation at start.

> It can be any chrome:// URI.

OK then I could be able to just map it using

root  zotero-better-bibtex  /

and use chrome://zotero-better-bibtex/root/prefs.js

[David Hoff-Vanoni]

Hi Emiliano,

I was curious about what you're encountering, so I downloaded the latest XPI and opened up the `defaults/preferences/defaults.js` file. I noticed a strange character on line 14 (see screenshot). Could it be that the presence of this character is causing Zotero to fail to parse the file?

[Dan Stillman]

On 1/26/23 5:46 AM, Emiliano Heyns wrote:
> OK then I could be able to just map it using
>
> root  zotero-better-bibtex  /
>
> and use chrome://zotero-better-bibtex/root/prefs.js

It doesn't need to be in the root if you're loading it yourself. Just
put it in one of your existing mapped folders and use the right URI.

You'll only need a copy in the root when you add a bootstrap version for
Zotero 7, and that can be copied in a build script if necessary.

[Emiliano Heyns]

Hi, thanks for looking into this. That character is there on purpose, I tried removing it, but got the same behavior. Setting the defaults as Dan pointed out does work though, and will have to be done in any case for bootstrapped.

--
You received this message because you are subscribed to a topic in the Google Groups "zotero-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/zotero-dev/HI7itFdtws4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to zotero-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/zotero-dev/6c3fc4e6-6641-4c4e-afb5-e75d8989dfd0n%40googlegroups.com.