This is a more major version bump due to Space Config, which is a bigger architectural change. It shouldn’t break anything for existing users — but you know — famous last words. Please report bugs as you find them, they may be there.
Without further ado…
Space Config is here! We hear you like Space stuff (Space Script and Space Style) so we keep adding more! This allows you to distribute your SETTINGS across pages. A few things of note:
This is quite a deep architectural change so I may have accidentally broken things I didn’t intend to, please report issues.
There is now a @config global variable that you can reference from anywhere containing the space’s currently active full configuration
There is now linting (checking) of space-config blocks, checking that you use built-in configuration keys correctly and reporting errors if not. Later this will be extended to allow plugs and space scripts to define custom validators as well (based on JSON schema).
Possible side-effect: if you configured a custom indexPage and are upgrading, it may be that your initial load brings you back to index. Just let the space reindex finish and reload and you should be good.
Plug developers: If you were using the readSetting library call, please switch to using the new system.getSpaceConfig() syscall instead once this is released. readSetting read the SETTINGS page only, this may now no longer give the full picture.
Added caching to file listings (useful for large spaces or slow disks) (by Justyn Shull)
I’m cc’ing @justyns@Maarrk and @joekrill here, because they have plugs that use the old readSetting API, please switch to using system.getSpaceConfig("mykey") for future releases, because you can no longer assume that settings are kept just in SETTINGS from henceforth.
Reload the page and force a cache refresh in your browser. On windows this is ctrl + shift + r
Some of my clients were caching old settings, especially those in sync mode. They didn’t seem to re-index, read settings through space-config etc until I did a couple of ctrl + shift + r’s
Another note: this release will kick off a full space reindex, and only after that your config may be complete. So if you have a large space, this may take some time. Watch the (server) logs to see if it’s still indexing.
There’s currently no way to support both pre-0.9.0 silverbullet and post-0.9.0 Silverbullet. In the treeview plug I tried updating the import to use v0.9.0 of the plug API thinking I could check the version and use getSpaceConfig if it’s supported, otherwise fallback to readSetting – this way the plug will continue to work for folks who haven’t upgraded yet. But because readSetting now actually just called getSpaceConfig, it’s always going to fail for anyone using < 0.9.0.
Should the API upgrades be conscious of these sorts of changes and fallback gracefully?
What I could have done is update the readSetting function with an attempt at calling getSpaceConfig and then falling back to the old implementation (just with a try-catch). I can still update the implementation to that actually, then you could rely on that implementation. This would then be part of 0.9.1, sounds reasonable?
A more “wreckless approach” would be to say: we’ll assume people regularly update SilverBullet, at least as often as they update plugs. So this should be fine. New users will also install the new version of treeview so all is good. People don’t tend to run “Plugs: Update” often (I imagine), and if they don’t the old version will keep working.
That said, let me just update the implementation so for 0.9.1 it will be nicer.
