Global Settings / Same settings, themes, and plugins across multiple vaults

Feature requests
81

It blew my mind that I spent all this time setting up obsidian only to discover that it only works for the particular project I had open when I was setting it up. These are general application settings that have nothing to do with the project and have no business being scoped to the project. I can’t imagine why anyone would ever want to scope things like keyboard shortcuts and gui themes for one individual project. I expect an text editor to have the same basic behavior regardless of what text file I am editing. Look at literally any other test editor. Now I need to memorize a different set of keybinds for every single project? What kind of insanity is this? Can we please give users a reasonably consistent experience so they can have a realistic opportunity to learn how to use the application?

Forget about per-project configuration. It’s not important. Just move all the configuration to be globally scoped. That’s the simplest approach that the small dev team should be able to handle easily. Per-project configuration is a “nice to have” that can be added on top of global configuration, but it’s pretty limited in utility. I doubt the vast majority of users would be interested in it. So let’s not worry about the complexity from managing separate configuration sources for now. Just make it exclusively global. Should be trivial for established users to migrate settings from a project folder to a global folder.

7 Likes
82

Not everyone’s vaults are scoped to project level.

2 Likes
83

I have a simple command-line tool I wrote in Python a while ago to help manage the settings files in the .obsidian folder: Obsidian Settings Manager (OSM).

OSM can:

  • list all your Obsidian vaults (I have more than three dozen, lol)
  • copy settings from one primary vault to the other vaults
  • execute a command against all vaults (e.g., git status)

I never made a big deal of announcing it, because the right way to do this is in an Obsidian plugin, rather than an external script.

But it is public and open source, and perhaps still of use. I haven’t updated it or stress-tested it in 1.5 years, but it still generally works. I can’t provide much user support for it, but I am happy to receive bug reports / feature requests in the OSM repo’s issue tracker, and would be happy to review pull requests. (Or to see it rewritten as an Obsidian plugin!)

Check it out: https://github.com/peterkaminski/obsidian-settings-manager

Please read the warnings and disclaimers before using Obsidian Settings Manager.

5 Likes
84

I realize a lot of the ideas below have been posted above, but it makes for difficult reading for half of this to be “as [username] said”.

$HOME/.obsidian

This will be exactly the same as the current per-vault directory, however all plugins and themes which are installed from any vault will have the actual js/css/manifest stored here. There will also be a data.json here, which will use the same developer API as the current per-vault one, just via Plugin.saveGlobalData/Plugin.loadGlobalData instead of the existing ones (no breaking change is an added bonus).

Also no workspace.json or other vault-dependent fields.

$vault/.obsidian

This remains mostly unchanged. The main difference will be that the plugins directories contain only the data.json file. It would be nice for plugin devs to have access to a Plugin.loadMergedData rather than being required to do their own comparisons and object merges should they need to handle hierarchy, which would also reduce plugin bundle size and execution times.

Changing and loading settings

Could do a deep merge on the JSON with every change, could do that with some fancy caching to save execution time,
Probably best to load the global configs, then iterate the local ones and set those for this app session. This ties in with the point below about global-first settings.
Additionally, when a setting is changed, no matter if local or global, Obsidian can just do what it’s doing now and set it on the fly without additional processing.

For storing the settings then, a toggle at the top of the settings subwindow (and other subwindows within such as themes or plugins) can have a simple toggle at the top for switching between changing globally and changing locally.
I would argue this should default to global, and if you close the settings then open them again, it should reset to global. To edit settings locally should require opening settings, and clicking a toggle.
My reasoning for this is because every other piece of software I’ve come across has global-only settings. People are used to changing a setting and it applying for all uses of the app. It’s the same reason content scrolls vertically and double-tap is like; everyone knows how it works, so working in the same way reduces friction. If a user changes something locally, works for an hour, then decides to change a setting, they won’t necessarily recall that they’re in local mode, even with the activated toggle.
The toggle should be labelled of course, “global settings” when off, “vault settings” when on, and an on-hover/focus tooltip on that text briefly explaining what it’s for an a link to the relevant section in the docs.

This toggle’s status should be made available on Plugin.vaultSettingsMode so plugin developers can have a signal for when their plugin might want to use Plugin.saveData vs Plugin.saveGlobalData.

It’s been two and a half years since this feature request was opened.
If developer time is an issue, I’ll happily come in temp and implement this for you as quickly as possible (email me).
If it’s a design choice to continue to not have this feature, that’s frustrating for a lot of us.

5 Likes
85

I want to have several vaults, but I want the same settings, keyboard shortcuts, plug-ins, etc. in each. Furthermore, if I change a parameter in one vault, I want to have identical settings in the other vaults. In other words, I want all settings to be global.

With this in mind, I have found a fairly simple solution that does not require installing any plug-ins. I have applied my solution to Windows. There are certainly analogous mechanisms available in other operating systems.

On my computer, I have created a Notes folder on my D: drive. In this folder I create further vaults. I currently have two vaults: personal and professional. The paths to the individual vaults look like this:

  • d:\Notes\personal
  • d:\Notes\professional

I created and configured one of personal vault. A .obsidian sub folder has been created in the vault. I closed Obsidian and moved this folder (cut and paste) to the main Notes folder. From now on, this is my main vault settings folder:

  • d:\Notes\.obsidian

Next you must perform the following actions on the command line. Run the Command Prompt as administrator. Now make junction point of the main settings folder to individual vaults:

mklink /j d:\Notes\Personal\.obsidian d:\Notes\.obsidian
mklink /j d:\Notes\Professional\.obsidian d:\Notes\.obsidian

A brief explanation for those who do not use Windows and are not familiar with this mechanism: junction point allows seeing the folder indicated in the second parameter also as the folder indicated in the first parameter. These folders can be on the same or different drives.

86

I want to be able to collaborate with other people on repositories & keep most settings at the repo level, but I also want to use vim keybindings without forcing everybody else to.

1 Like
87

Obsidian having custom settings per vault is a great feature allowing for flexibility. However, it also means that every time I create a new vault I have to go through & manually set all my settings back to the way I prefer. I imagine most people will have their own custom default that they’d prefer to start new vaults with other than the “factory” default that Obsidian ships with.

It would be great if there was a “Make Current Settings Default” option that could be triggered. All new vaults created thereafter would use the settings that were enabled when it was triggered.

Also to aid in troubleshooting it would probably make sense to also include a “Restore Factory Default” settings ability.

I suppose another option would be for all new vaults to use the current vault’s settings. Most people will likely only make small changes from their preferred settings for any new vaults. It’s easier to remember what you want to change from where you already are, than it is to to get to where you want from an unfamiliar state.

18 Likes
88

The way I have been dealing with this is copying the .obsidian folder and obsidian.css in to my new vault.

Or you could duplicate the entire vault, change the name and then remove all notes inside.

Not idea, but it works well for me

8 Likes
89

seconding this request!

1 Like
90

+1
this default settings may contains:
plugins, themes, configs.

3 Likes
91

I would also find this very useful.

1 Like
92

Copying the contents of the .obsidian folder worked for me. Good one!

93

+1
It’d be good if a $HOME/.obsidian/ were replicated in each new vault…

3 Likes
94

This would be tremendously useful. It would allow for using the “Open folder as vault” option to effectively open a temporary vault to work within a given thought context.

For me, this would effectively solve the problem I outlined at Context Overwhelm, Concentric Vaults, and Sensemaking - Thinking On Thinking In Notes - #2 by realactualprice.

5 Likes
95

i have barely started to use obsidian but this is already the first feature i want that i was surprised wasn’t already a thing. i even tried closing all vaults and selecting the “Settings…” menu, thinking i might be able to set global defaults that way, but that just shows me a javascript error dialog (on mac).

for now i will copy the .obsidian folder. thank you for that tip! i hope someday this extra bit of friction can be reduced.

1 Like
96

Gonna throw my vote in for this as well. Was rather surprised it wasn’t already a thing.

2 Likes
97

Use case or problem

I want to have my configurations/plugins/themes all standardized between my vaults, making it machine-wide.

Proposed solution

Let us put the .obsidian folder outside of the vault (preferably in the Obsidian installation folder) and point our vaults to it allow us to have a machine-wide configuration.

Current workaround (optional)

Using symbolic links. It’s not user friendly or safe.

9 Likes
98

My other workaround is to have a script that copies the folders periodically across vaults.

Also not user friendly, but a little safer than managing a symlink.

1 Like
99

Having a hidden .obsidian folder per vault (much like git) has pros and cons, like everything. I was originally against having to set up everything again for every vault, but eventually found out that the pros outweigh the cons, at least for me:

  • Turned out I’m not using as many vaults as I originally thought. I actually put my personal, professional, and writing “digital life” into just one, eventually. It’s so much easier to handle, and fast enough.
  • I mainly use 3 devices for the same vault: A Linux desktop, a Linux laptop, and my Android phone (no Obsidian here, just Markor to handle the inbox and to-dos).
  • So having “everything in one box (folder)” is a great plus for syncing between devices (I use Syncthing): I have to sync just one folder and don’t have to mess trying to sync system folders, or parts of them.
  • Having to backup just one set of folders is also a plus (I use (g)rsync). You’re always sure to have it all.
  • Yes, I do use a (very) few symlinked files and folders outside the Obsidian vault, but since these are in identical locations on all three devices (below the “Documents” folder), I can simply sync/backup those as symlinks.

So in my case practical use has shown that I’m actually quite happy with the developers’ original decision of “one set of settings per vault”.

I still see your use case, and I wonder how easy or compatible it might be to maybe have a “main vault” and just symlink all other vaults’ .obsidian folders into that. Don’t know if that would break anything (assuming that all plugins use relative paths, that is). Also, I’m a little unsure about how robust symlinking on Windows might be.

2 Likes
100

(1) Standard model for this would be a configuration in OS standard user-space location, typically either (older convention):

~./obsidian

or:

~/.config/obsidian/
~/.local/share/obsidian/settings

etc.

Then settings in a local vault ~/path/to/vault/.obsidian will (selectively) override the host-specific settings in ~/.config/obsidian.

(2) It would be nice to go one step further, and for Obisidian to store cross-device configurations in the cloud, synced server-side, with the host-specific ~/.config/obsidian settings selectively overriding this, and the vault-specific ~/path/to/vault/.obsidian selective overriding this.

(3) Personally, when I first started, I had all my vaults in their own Git repo, but the .obsidian subdirectory in each repo a submodule. Lots of ways to get these to autosync, but before I figured out a working solution, I evolved toward just one single vault for everything and the problem went away :rofl: … for the time being until my system changes again :sweat_smile:

5 Likes