assets comprises thousands of files I link to using _canonical_uri – almost no binary data is in as a tiddler.
single-file-snapshots are automatically created at set intervals by a script that checks if tiddlers/ has been updated.
I am looking to:
Create a new wiki using most of the plugin configuration of my existing wiki.
If needs be I can manually migrate the config & plugins, but I was wondering if most configuration & plugin stuff can be shared through MWS.
Split out tiddlers related to a work engagement into a new 2nd wiki, away from my personal wiki.
The new wiki must:
Use the same directory tree for _canonical_uri and other links (so linking to assets/ directly) – as I have various scripts that write to it
Have the possibility of being exported to single-file in an automated way, ideally in two separate wikis
It would be nice if I could:
Use the same configuration & plugins across both wikis through MWS as a ‘single source of truth’ (mentioned above)
Continue to interact with tiddlers directly on the filesystem, instead of relying wholly on a SQL database
So in essence, I want to end up with 2 separate “content wikis” that use the same base configuration.
Is this a use case I can meet with MWS? How would I go about it?
The short answer is “yes”, this is a use case that works in MWS.
Each wiki is defined by a “recipe”, and each recipe can hold one or more “bags” of tiddlers. The way I’ve used this is to create bags for specific plugins (eg: one for codemirror-6 plugin, one for the Notebook theme, etc) and then reuse those bags in multiple wiki recipes where I want that particular feature. You could put your shared plugins and configuration into one or more bags, then define two recipes for “content” wikis that share all of the plugin bags, but have a different top-level bag for storing the content.
The slightly longer answer is that setting all of this up is currently a bit of a process and I don’t think that MWS currently does everything that you’re asking. I’ll try to respond to each point:
I can’t currently find any way to serve static files with MWS in the same way that the Node.js server does it. I’m not sure that this is a planned use-case for MWS. However, I was able to make this setup work by adding a webserver (Caddy in this case) to serve the static files and reverse proxy to the MWS server.
Example Caddyfile
localhost:8443 {
root * path/to/wiki/
# route is needed because file_server has lower
# priority than reverse_proxy
route {
# serve static files from the assets folder
file_server /assets/*
# send all other requests to MWS
reverse_proxy /* 127.0.0.1:8080
}
}
This is not currently implemented, as far as I’m aware, but it should be possible. This can be added to the requested features if it isn’t already there.
Yes, this currently works with the “bags” and “recipes” model as explained at the top of my post.
Also not currently implemented, but may be possible. The database is the source of truth for tiddlers in MWS, but there’s no technical reason (to my knowledge) that some sort of database → filesystem synchronization couldn’t be implemented. I don’t know how big of an effort this would be.
@Arlen22 , please correct me if I’ve gone astray in my descriptions of current or planned functionality.
I would also like to point out that regardless of if you are sitting on top of MWS (I assume) node, desktop or even single file wikis, the “spawning of new tiddlywikis” is part of its core behaviours.
The save/download mechanisms that make tiddlywiki a true “non-trivial Quine” on any version of tiddlywiki.
This is primarily driven by a template and filters that constructs a resulting html file