Variable to access other plugins' configuration?

[kg4zow]

If there isn't already a way to do this, I'd like to suggest a mechanism to access other plugins' configuration values.

In my specific case, I needed a way to access the "Daily note" plugin's "Date format" and "New file location" values. I've written a script that copies the current day's "Daily note" to a shared drive, and I need the script to be able to find the correct source file. It started with the paths hard-coded into it, but that means people need to edit the script before using it, and I'd rather it be a drop-in thing if possible. (This page has details if you're curious.)

I ended up having the script manually parse the .obsidian/daily-notes.json file to get the values I need, but I wonder if there isn't a "cleaner" way to get these settings from Obsidian and pass them to the script as command line options. I haven't looked at Obsidian's APIs in detail (I have very little experience with javascript, I'm an old school C/Perl programmer and was doing DEVOPS before the name existed) so I honestly don't know if this is even possible.

Does Obsidian even have an API where a plugin is able to access other plugins' settings, or are plugins "sandboxed" away from each other?

[Taitava]

Hi! You are correct, the SC plugin doesn't currently offer any way to do this.

I can't be certain, but if I remember correctly, there might be some private API way to access other plugins' configurations.

At least accessing the Obsidian main settings are discussed here: #321 . That would also be using private API.

Private API means that officially Obsidian API does not provide a way to access private API content, but there's no sandboxing preventing doing it. It just means that things relying on private API may break when Obsidian updates or other plugins update. For a variable like the one you suggested, I'm ok to use the private API route - if it breaks, it won't break the whole plugin - only this particular variable.

However, I can't promise any schedule for this.

Anyone wanting to contribute? 🙂

If someone is willing to use some time for this, a pull request is welcome.

• A new subclass of Variable could be created. Set variable_name to plugin_configuration.
• Instantiate the class in loadVariables().
• Implement the logic for retrieving configuration values via the private API.
• The pull request can be a working draft - I'll do some finishing anyway.
• I'll write documentation.

[kg4zow]

I didn't realize there wasn't a standard API for plugins to store configuration data.

Maybe it would make sense to ask the Obsidian core team to make the currently "private" API, public? Or to create a public API and encourage plugin authors to use it, so that there is a more-or-less standard way to do this?

[Taitava]

I didn't realize there wasn't a standard API for plugins to store configuration data.

Are we now talking about community plugins or Obsidian's core plugins?

To my understanding, there is a standard API for community plugins to store configuration data: Plugin.saveData() saves the plugin's settings into .obsidian/plugins/pluginName/data.json. The file name is the same for each plugin.

Maybe it would make sense to ask the Obsidian core team to make the currently "private" API, public? Or to create a public API and encourage plugin authors to use it, so that there is a more-or-less standard way to do this?

I'm not so certain about the public API route here, at least for community plugins. Even if there would be a public API to access other community plugins' configurations, there would still be a need to know which properties are available in a particular plugin's settings. And that knownledge - even though it can be read from the data.json file of each plugin - is in my eyes private API anyway. Maybe the most official way would be for users to ask each community plugin authors to define a public API that provides just the settings the user particularly needs. But that would be quite an effort (to request a public API and for the plugin developer to implement one), considering the fact that the settings are already stored and readable in the filesystem.

But for Obsidian core plugins, maybe it might make at least a little bit sense to have a public API to read their settings? I can see two problems there for Obsidian:

• They might need to make the settings available as read-only, i.e. would probably need to clone the settings object that is provided via the public API, and redo the cloning after settings are changed. Otherwise, community plugins might break Obsidian if they could modify the settings without knowing each setting well.
• They would lose the freedom to rename and restructure their settings. Every structural change to settings would require community plugin developers to update their codebase accordingly.

Anyway, a request for Obsidian to create a public API for reading (core or community) plugin's settings would probably need some well argued benefits for it to succeed. Reading data from Obsidian perhaps might not be high in their priority list, considering the volume of feature requests they get and the fact that the settings data is already readable from the filesystem.

My current thinking is that I'd go with the private API route for accessing Obsidian's core plugin's settings. Maybe I'd leave community plugins out of this in the first phase, at least if they are harder to read. If someone is interested to write a request for Obsidian to make a public API for this, I'd be glad to use the API, but I'm not really prepared for having the discussion myself. 🙂