Came here looking for a solution for global settings, saw this thread. +1 to this feature. 
2 Likes
Same here, I’m starting out and only have 2 vaults and the frustration of “why isn’t this working I already changed the hotkey (or some other editor setting)” has already bitten me.
A home directory to store the global settings that are overridable by each vault setting sounds great to me.
1 Like
I’d like to expand this to include Plugins, CSS etc… It seems to me that all of this should be stored in a global obsidian repository, and then vault-level preferences select/apply what is wanted/needed. If I’m not mistaken, VS Code is basically like this - Extensions, Themes, Settings etc… get applied per Workspace.
As it stands, I have different plugin versions installed in different vaults, when you’d think that updates would be applied globally (along with being able to select which plugins are turned on for each vault, and how their settings are configured in each as well)
Are there any benefits to having the per-vault settings (hotkeys, plugins, css etc)? I can’t come up with a single one.
2 Likes
Well, there’s no reason to activate the daily notes plugin in a vault with no daily notes, Zettelkasten where you’re not using Zettelkasten, file explorer in a completely flat vault, etc. etc. You might want different themes to visually distinguish your vault windows. On and on and on…
That being said, having a global hotkey configuration is an excellent idea, as is the ability to specify plugin default settings and global defaults.
I’ve been thinking a bit about making a settings-sync plugin that would let you update vault settings to match changes in a per-user file, and vice versa. It’s potentially quite doable, but certain aspects are challenging because Obsidian and its plugins save all settings, even ones that are still in the “default” state, and there is no way to distinguish between “this setting is still in the default state” and “this setting was deliberately set to the default”… which is kind of important for such a thing.
That can be worked around, though, by the plugin keeping a local record of what it has or hasn’t “published” to the main config and what settings have been chosen to “override” the local settings.
The other big complication is naming/documenting settings, as plugin’s settings .json files aren’t documented in a way that a settings sync plugin could use to provide a helpful UI.
1 Like
But is there really any harm in Daily Notes being active even if you’re not using it? Just don’t use it - same for ZK etc. The tiny amount of extra memory used is a small price to pay vs. having to reconfigure these plugins for every vault.
On your other point about different themes for each vault, yes I can see that being useful. Theme and individual CSS snippet toggles should be a per-vault setting. The CSS snippets repo itself however, should be global.
I admire your ambition to want to roll your own plugin to handle this, but I think something this close to the core should be done natively and with full support of the devs behind it. Anything less will most likely just lead to bad things happening.
2 Likes
@luckman212: I totally understand where you are coming from. But perhaps there is a solution that could address both of our concerns. You asked about:
Although I probably am in the minority opinion for this, I like the option of having the ability to install a few plugins for a specific vault then back that up onto an external hard drive and keep my current operating system drive only with vaults that have no plugins.
Then, when I want to use a certain plugin feature with that specific set of content, I can connect the external drive while offline, and use it to accomplish a goal knowing my important vaults on my operating system are locked down and encrypted during this process. I also know that none of my important vaults are affected or have to install new updated versions of plugins just for this purpose.
I am sure there are other reasons why separate vault settings are helpful. But if I knew installing a plugin meant having to “reinstall” it for all vaults and regularly letting them connect to the internet, I’d be less likely to install some plugins.
I know I am a bit paranoid in this sense, and do understand there are very few limits on what electron apps can access, but this at least makes me feel I am doing my best to be careful. I figure that as time goes on with no issues arising, more trust can be established and things will change for me.
Thanks
Virtually every plugin I make is like that, actually. Hot-reload, symlinks, note folder autorename… even Tag Wrangler. Definitely the ones I haven’t released yet (like Pane Relief). I’m not really sure what “bad things happening” you mean, either.
But as far as syncing settings go, a plugin for that isn’t even all that ambitious, so long as you reload the vault after importing new settings. I’ve previously written a modular configuration management system for Wordpress, which has, shall we say, a far less elegant and uniform approach to plugin configuration. (For example, in WordPress there’s no way to programmatically tell what settings belong to which plugin.)
Anyway, if I can do that without the WP core devs “full support”, I don’t see why I’d need it for Obsidian. (Not that I have any plans to do it any time soon; my Pane Relief plugin is much higher up on the priority list for finishing and publishing, once I get per-pane history done and maybe an option to prioritize activating existing panes over opening new ones.)
One very simple example: Different daily note formats for a work vault, and a different format for your personal notes or journal. I’m sure there are many more examples. While I understand that this might not work for you that doesn’t mean there aren’t use cases out there.
1 Like
@Klass You can do this with a LaunchAgent — specifically the WatchPaths directive. The agent would run when your css file is modified and can trigger a simple shell script to run & copy the file from A to B. If you’re totally new to launchd, I suggest a GUI to configure it such as LaunchControl.
1 Like
I’ve created several vaults, all with different configurations – plugins, templates, etc. I would like to standardize all the vaults on the same configuration.
Problem two, once I’ve done the conformation, I would like to keep these configurations “synchronized”, as it were.
Any suggestions?
symlinks will help you sync them. But it won’t give you an option to confirm. instructions are at https://www.howtogeek.com/howto/16226/complete-guide-to-symbolic-links-symlinks-on-windows-or-linux/
3 Likes
That is not relevant.
Not sure if this has been already implemented, but I would very much love if there is an option for global settings config, which is applicable to all vaults.
1 Like
Use case or problem
For someone that uses multiple vaults to separate projects, the ability to enable/disable plugins and have them maintain state per vault is awesome. The need to re-download a community plugin that you use all the time, however, makes little sense…especially when factoring in the need to update plugins.
Proposed solution
There are likely multiple ways to implement this, however a centralized local ‘community plugins’ repo that obsidian is aware of (either a database or folder repo with some sort of list that tracks which vault uses which installed plugins) and can offer symlinks to plugins that are frequently used, might be a way to implement it.
Pros:
- Instead of having to re-download each time you make a new vault, and having to spend time updating plugins across each vault as you access it, this would save time in ‘micro-transaction’ style that eventually builds up to more time saved…a good feature for a program that seems to be all about efficiency.
- Centralizing plugin management will make it easier/faster to dig out any plugins that become an issue across vaults due to either corruption, bad code practices/security issues, or malicious code.
- Saves space! Yeah, I know, each plugin is only a couple hundred kb in size and hdd’s are (relatively) massive now and this is likely a non-issue for most, but for those people or organizations that do deep scans on viruses/malware etc. or run software that for whatever reason runs iterations through system folders, it could reasonably help cut down processing time for those types of programs. - Like I said, probably a non-issue for most.
Cons:
- possible need to rewrite the way community plugins are handled.
- easier for a ‘destructive’ plugin to damage multiple vaults
request for comment:
I’m sure there are other pros and cons to restructuring how plugins are handled, however I’ll leave it to others better versed in Obsidian, its code and how plugins are handled to hash that out in the comments.
Thank you for your time and consideration of this request.
~ D
4 Likes
Is a global setting for all Vaults still missing?
4 Likes
+1000 for this one, thanks for delivering such a great app!
Still not supported?
+10086!