Tiddlystow a(nother) native file saver

[btheado]

Store TiddlyWiki files locally using the browser file system api

This simple web page is a helper for loading a local TiddlyWiki file and storing it back to the same local file.

Features:

• Works with any single-file TiddlyWiki instance version 5.1.23 and later. No plugins required thanks to the custom saver feature!
• Open from and save back to local files
• Shortcut buttons for recently opened files
• Open a new, blank TiddlyWiki instance from https://tiddlywiki.com and save it to a local file

Try it at TiddlyStow - stow TiddlyWiki files locally using the browser file system api.

@slaymaker1907’s TW5 browser nativesaver is a similar project, but has more features and is bundled as a TiddlyWiki plugin.

Tiddlystow is a only a launcher and doesn’t itself contain any tiddlywiki functionality and is not implemented in tiddlywiki. It is just a short(ish) html + javascript file. Visually, the page is very lacking, but the basic functionality is there.

I implemented this to illustrate a workflow which alleviates the concerns about @slaymaker1907 's plugin that I shared here:

[tw5] Major updates to Chromium native file system saver plugin

As inspiration, this seems to be a decent implementation of native file storage API: https://bangle.io This does look pretty good. Another example is https://app.diagrams.net/. These two apps have a webpage at a well-known url which holds the javascript functionality. The data files are loaded in separately. Compare this to tiddlywiki in which the functionality and the data is combined together into a single file. I think to implement the same workflow in tiddlywiki, you’d have to have a “l…

[Mark_S]

Looks interesting!

Can we download and use this file locally, or does it have to be hosted somewhere? Needing a remote site in order to use a local file is somewhat unexpected.

I suspect that people will need some way to delete existing entrees. Either to erase their history or perhaps because a TW file has a new file location.

[jeffrey]

Tested and looks great! It is like a alternative for the timimi extension.
I see a frame out of any tiddlywiki, is it a bug or necessary for this saver?

It looks like this:

[btheado]

@Mark_S

Can we download and use this file locally, or does it have to be hosted somewhere? Needing a remote site in order to use a local file is somewhat unexpected.

The file does work fine locally. I did test it. I forgot to link to the source code: GitHub - btheado/tiddlystow: stow TiddlyWiki files locally using the browser file system api · GitHub. You can download the index.html from there.

However, I was lazy with the implementation and used two external javascript libraries. Even if you download the file, it will still require network access.

A fully offline version probably isn’t much work. Either bundle the dependencies, or rewrite so the dependencies are not required.

@Mark_S

I suspect that people will need some way to delete existing entrees. Either to erase their history or perhaps because a TW file has a new file location.

The list of recent files is capped at 5, so older entries will go away. I agree, more control would be useful to the user.

[btheado]

@jeffrey

I see a frame out of any tiddlywiki, is it a bug or necessary for this saver?

This is the way I initially implemented it. It worked when I loaded the tiddlywiki file contents into an iframe and I didn’t explore other options.

Maybe the iframe can be styled to make it invisible? I’m not sure.

I noticed when writing my initial post that default-kramer wrote the following in his pull request which implemented the custom saver feature (add override saver by default-kramer · Pull Request #4908 · TiddlyWiki/TiddlyWiki5 · GitHub):

then it uses document.write to replace the entire document (see: https://stackoverflow.com/a/4292640)

Since that worked for him, it should be possible to not use an iframe at all.

[btheado]

@btheado

Since that worked for him, it should be possible to not use an iframe at all.

It did work and I pushed the change. The code no longer uses the iframe so the border issue and nested scrollbar issues are gone.

[btheado]

@btheado

However, I was lazy with the implementation and used two external javascript libraries. Even if you download the file, it will still require network access.

A fully offline version probably isn’t much work. Either bundle the dependencies, or rewrite so the dependencies are not required.

I made these changes and the file no longer has any dependencies. Now you can download and use the file locally even while offline.

@Mark_S

I suspect that people will need some way to delete existing entrees. Either to erase their history or perhaps because a TW file has a new file location.

I took a simple-to-implement, coarse-grain approach and added a button which will clear the entire recent list.

[CodaCoder]

Maybe point out there’s no Firefox support (yet).

https://caniuse.com/native-filesystem-api

[slaymaker1907]

Fantastic work! I intentionally designed the plugin version to work primarily with single file wikis (since I love the concept of a single, self-contained wiki), but I like the approach of this as well.

Concerns about combining code+data was a large motivation for adding the limited backup feature of the plugin. I’ve been bitten before by messing with plugins and effectively corrupting the wiki to the point that it is difficult to repair.

I didn’t know the override saver was a thing, but that solves a lot of the problems I had when trying to implement something similar using a syncer instead of a saver module. Another idea similar to this approach would be to only save data tiddlers (and not core or plugin tiddlers) that way you can have a set of common plugins across various mini wikis. While Tiddlywiki is good for large, monolithic wikis, it can be somewhat lacking when you want to have mini wikis with their own namespacing, but common themes/plugins.

[slaymaker1907]

It’s also very limited with Safari as far as my testing shows. I think Safari only supports the origin private file system and not actual access to the file system. This is certainly true for mobile, but I haven’t been able to test it on Mac.

[CodaCoder]

@slaymaker1907

It’s also very limited with Safari as far as my testing shows.

It’s supposed to be partially supported and “released” in their Tech Preview build according to caniuse.

[Charlie_Veniot]

@btheado

Tiddlystow is a only a launcher and doesn’t itself contain any tiddlywiki functionality and is not implemented in tiddlywiki. It is just a short(ish) html + javascript file. Visually, the page is very lacking, but the basic functionality is there.

I finally just got around to giving Tiddlystow a spin.

I really like it. Very good stuff.

[TW_Tones]

I too only got to play now.

• Noted not working on firefox
• I hope some feedback is still welcome?
• This has enormous potential - thanks

I was taking notes and preparing questions but I am finding answers to many of them already.

I will post later, but there’s already enough to work with.

[Charlie_Veniot]

A problem I’ve just identified (not a dealbreaker, but something to watch out for):

Working with a TiddlyWiki opened with Tiddlystow, I just noticed the URL to the TiddlyWiki is showing the URL to TiddlyStow. Makes sense: how else is Tiddlystow supposed to catch when the save button is pressed in TiddlyWiki?

However, I think that will cause all kinds of problems.

The first one I’ve identified: permalinks to tiddlers.

Permalinks are screwed up, because they are giving links that are to Tiddlystow, with #tiddlername appended to that URL.

So using Tiddlystow to open and save a TiddlyWiki is awesome, but things get wonky if that TiddlyWiki needs to use the TiddlyWiki instance’s URL for anything.

Not sure I’m explaining all of this right, so please open your TiddlyWiki via Tiddlystow, and look at the $:/info/url/full tiddler, and paste the permalink to any tiddler into a new web browser tab to see results.

[btheado]

Thanks for the report.

@Charlie_Veniot

Not sure I’m explaining all of this right, so please open your TiddlyWiki via Tiddlystow, and look at the $:/info/url/full tiddler, and paste the permalink to any tiddler into a new web browser tab to see results.

The behavior I see isn’t ideal, but it works as I expect, only with an extra button click required.

1. open a tiddlywiki via tiddlystow
2. Open some tiddler
3. Click the permalink item from that tiddler’s “more actions” menu.
4. Paste the permalink in a new tab
5. The original tiddlystow page loads. The #tiddlername is still appended to that URL
6. A button for all the recently opened wiki’s are listed on that page
7. Click the button to open the tiddlywiki on which you captured the permalink
8. The wiki loads and the permalink is processed. The tiddler corresponding to the permalink is opened as expected.

Is item number 5 above the “wonkiness” you observed or is it something else?

I agree it is less than ideal. Step 5 is likely confusing and step 7 is an extra step the user has to take and it will be even more confusing if the user opens a different wiki for which the permalink doesn’t match with any tiddlers.

Maybe the javascript on the tiddlystow page can look at the url parameters and do something to make it less confusing. I’m not sure.

[Charlie_Veniot]

@btheado

The behavior I see isn’t ideal, but it works as I expect, only with an extra button click required.

1. open a tiddlywiki via tiddlystow
2. Open some tiddler
3. Click the permalink item from that tiddler’s “more actions” menu.
4. Paste the permalink in a new tab
5. The original tiddlystow page loads. The #tiddlername is still appended to that URL
6. A button for all the recently opened wiki’s are listed on that page
7. Click the button to open the tiddlywiki on which you captured the permalink
8. The wiki loads and the permalink is processed. The tiddler corresponding to the permalink is opened as expected.

Is item number 5 above the “wonkiness” you observed or is it something else?

I agree it is less than ideal. Step 5 is likely confusing and step 7 is an extra step the user has to take and it will be even more confusing if the user opens a different wiki for which the permalink doesn’t match with any tiddlers.

Maybe the javascript on the tiddlystow page can look at the url parameters and do something to make it less confusing. I’m not sure.

Yup, what you are describing is what I’m experiencing up to step 5.

Steps after 5, I had not tried until just now. That all works as you describe.

I have some TiddlyWiki’s in which I show tiddlers between each other via iframes. I’ll have to be careful how I grab URL’s in those cases. (i.e. make sure I don’t open those TW instances with Tiddlyshow when I want to grab a URL from one TW to add as an iframe src in another TW.

Not something I do all that often, so I think it will be okay.

[mwiktowy]

I have finally tried TiddlyStow and have to thank @btheado for a really nice tool to help saving locally.

I really hope that the API stabilizes/improves enough for Firefox to get on board and for some of this to be adopted natively into TiddlyWiki rather than as a wrapper. The hoops that are needed for local saves of single-html TiddlyWikis, while not particularly onerous, are sufficiently awkward enough to kill wide-spread adoption for those not savvy enough to realize that web browsers can indeed view local files (which is a surprising number of people in my workspace).

Keep up the good work in making single-html TW functional since it does serve some of us unable to run node-js on networks we don’t control.

/Mike

[stobot]

I apologize for the reviving of an old post but thought it made sense to keep the question with this thread - is there any way to keep the favicons from the loaded wikis? I run a series of them all open in tabs and it seems to only show the Tiddlystow logo. Great tool by the way, I’m exploring (like others are) with the concern that Timimi is going away.

[Mark_S]

I notice the same thing with TiddlyHost.

[btheado]

@stobot

is there any way to keep the favicons from the loaded wikis?

I investigated a bit and I’m not sure why the $:/favicon.ico is not being displayed in the tab. From my experiments on Linux chrome I’ve discovered the following:

1. Any resize of the browser window causes the internal favicon to appear
2. Adding the below button/action-setfield code and clicking on the button causes the internal favicon to appear
3. Adding the same action-setfield code to a tiddler with tag $:/tags/StartupAction/Browser (https://tiddlywiki.com/#StartupActions) does NOT cause the internal favicon to automatically appear

<$button actions='<$action-setfield $tiddler="$:/favicon.ico" forceupdate="1" $timestamp="no"/>'>
update favicon
</$button>

So far just these manual workarounds. Not sure how to get it to work automatically.