[bug] Server uses wrong SETTINGS.md file when multiple exist in space directory

[bonsairobo]

I have both a SETTINGS.md and a blog/SETTINGS.md in my space directory so that I can have another read-only instance running in the blog/ space directory while I edit from the writable instance.

So I also set a different indexPage in each of my settings files. This is how I noticed that my writable instance is using the blog/SETTINGS.md instead of SETTINGS.md. It sends me to the wrong index page. I confirmed this is the case because after I delete blog/SETTINGS.md, the bug goes away and I arrive at the correct index page again.

[zefhemel]

Well... technically this is as it should work. As of the introduction of Space Config the SETTINGS file is no longer special. SilverBullet is configured by merging all space-config code blocks it finds in your space. However, when it finds duplicate keys (like if you set the same setting in two different pages) the one that "wins" is undefined.

I'm thinking what could be a work around for your specific (unusual) use case, and not sure about it beyond creating copies of your space and deleting one or the other SETTINGS page for each, which isn't amazing either.

[bonsairobo]

your specific (unusual) use case

Is there a more usual way of accomplishing this? It's pretty nice having live updates. I needed to use SB_KV_DB to point the read-only instance at a different directory to avoid confusion between the two instances. Maybe I should also be able to place SETTINGS in that separate directory as well? (i.e. https://github.com/silverbulletmd/silverbullet/issues/1048)

[bonsairobo]

Another option would be to allow SETTINGS to specify a priority for options so that merging is well-defined.

[Ben7on]

A workaround could be to mount the settings file only in the container for the read-only instance. So the admin instance doesn’t see two settings file.

[zefhemel]

SETTINGS is no longer a thing in v2.