New repository for storing tiddlers in browser that I found on Github:
Not the author, just sharing the find!
Thanks, @anthrospeak. I’m the author and hadn’t gotten around to sharing it here yet.
More details from the readme:
This plugin contains opinionated configuration settings for the browser-storage plugin:
- Configures the browser storage plugin to save more tiddlers than the default
- Since the tiddlers are automatically saved to local storage, the SaverFilter is configured to leave the save icon inert
- Automatically save open tiddlers between sessions (see $:/DefaultTiddlers)
- Instructions on using the save button as a way to backup the wiki
- Browse-able list of tiddlers which were loaded from storage and those which were saved to storage after load
- Displays a notification message at startup telling how many tiddlers were loaded from browser storage
Contains browser storage improvements which have not been merged into master yet:
In addition I mark browser storage tiddlers with a cylinder icon in the tiddler view toolbar.
The demo is available at https://btheado.github.io/tw-browser-storage/. This demo is fully functional and might serve as a good entry-level wiki for someone who doesn’t want to spend time figuring out how to setup a convenient saver. Plugins can be installed, even ones which require reload due to javascript.
3 Likes
@btheado nice and important piece of work. I am reviewing it right now.
- It follows a design pattern I have being interested in developing for some time, allowing local storage first, then save as backup, and avoiding the saver complications. Perhaps tiddlywiki’s biggest deterrent?
- In effect this, and my ideas below, supports using the “default saver” mechanism, in a user friendly way and thus circumventing the saver complexities and helping when the local machine does not allow installs.
If we could collaborate on this I have some ways to make this overall solution more robust and self explanatory, it may make tiddlywiki’s much easier to adopt without the complexity of installed savers and servers.
The following text is somewhat technical and assumes the reader understands the context. I am happy to explain more if asked.
Observations
- From a user experience perspective returning to the “site” they will see the result of what they stored in local storage, if they are in the same browser.
- Unfortunately if the local storage is lost or they launched a different browser they may arrive at an empty unmodified wiki.
- If the user had saved localy a backup such that they could reapply the changes, they may not recall they had a backup and what its filename / location is.
Here are examples for which I already have working solutions. I have working proof of concepts already.
Named local backups and reload
- Making use of the wikis published address, to generate a filename for the saves/backups programmatically. Encourage the user to only use this filename, then if lost, the backup “file(s)” can be searched for localy.
- When loading the wiki and no local storage is available, prompt the user to confirm this is a first visit OR to locate their saved backup(s) and load it, in this case we have a known filename to look for.
Capture the backup in bookmarklets/cookie/local storage
- If the user saves the backup with a known filename, they can search for it (as above) but it is also possible to capture and store the full path and filename using the local operating systems file manger.
- If we store this separately from the wikis local storage, then we can provide the previous backup path, even if we arrive at the site with no retained local storage.
- We could even encourage the user to access such a site using a custom bookmarklet that provides the URL but also the backup path (If it exists) such it can be restored from the backup path.
The copy paste paths trick
- When initiating a backup or restore, if you have stored the full path and filename (eg in a bookmarklet or wiki) you can copy this to the clipboard, and the user can paste the full path into the “filename” of the “file open” or “save as” dialogue, then load/save (without even navigating to the folder).
- A save or restore button could display a modal with instructions to support this feature, and guide the user to saving or loading using a “known” local location.
Advanced bookmarklet use
- If using a bookmarklet we can also programmatically generate a target or window name when we open the wiki.
- Subsequent links can thus cause it to open in the same window/tab
- For multiple file:// wikis In fact it is possible to register named windows, in local storage for window management.
Local files
- This “combined solution” could permit users to save a copy of a wiki to a file location, open in the browser and leverage the local storage, in this case we already have access to the full local path and filename, and again do not need a local saver installed.
Have any .json containing the functionality?
Is this similar to how $:/config/SaveWikiButton/Filename can be used to set the download filename?
Do you have your browser configured to prompt for filename for downloads? Otherwise how are you getting a “save as” dialog?
Yes, in a range of configurations, some in bookmarklets.
- However I have not built a set specific to the proposed solutions yet.
- More to the point set the filename, but store or construct a full path and filename, and use this in the save dialogue to paste the full path and save.
- I currently use a version of this to distribute JSON packages, save the package to disk, capture the full path and filename and store in the package, and save again, the first time only. Now click a button to copy the full path and filename to the clipboard, to disk and also do either of the following;
- Export actions to trigger save as dialogue, paste full path, to export
- Import actions to trigger open dialogue, paste full path, to import
- I construct the full path and filename programmatically, or capture it from the file system, and trigger an or export. See tm-download-file. As suggested once you capture the full path and filename for the safety copy, you can encode this in a bookmarklet, save it in the browsers “bookmarks” rather than in the wiki, should the wiki forget it.
- The thing is once you select a place to store the file locally this need not ever change.
Of course there is more detail behind each of these mechanisms which I happy to share.
- With this upside down model, where we “save” in the browser local storage and store the backup or “safety copy” outside the browser, the user interactions change from needing to save, to needing to backup. Thus you need not backup every time, just at the end of each session or few days.
- And if you loose your wiki in browser storage, a bookmarklet will help you reload from the backup.
I still don’t understand. What steps are your taking to see a Save dialog box? Do you have your browser configured to do that?
1 Like
@btheado I am not sure what you are looking for or not understanding, perhaps this example shows something similar, drop on tiddlywiki.com, it places an icon in the Page Controls and will download as mywiki.html not the default tiddlywiki.html
download-wiki.json (1.7 KB)
This results in a save dialogue that will save the whole wiki including current unsaved changes.
- In my advanced solutions the same button would also copy thje full path and filename to the clipboard, then in the save dialogue I would hit
ctrl-Von windows to paste it into filename: of the save as dialogue.
Does that answer your question?
[Edited] if we store the path and generate the save filenames we could cycle through backup filenames like the tower of Hanoi. If restoring, the user will navigate to the folder, sort and open the latest.
- backups can be only the differences from the published wiki or a whole wiki. If a whole wiki, more may be needed to manage the restore.
This is the part which was confusing me. I think in order to see the save dialog in chrome you have to go to chrome://settings/downloads and enable the “Ask where to save each file before downloading”
option.
Firefox has a similar “Always ask you where to save files” setting in about:preferences.
After I make those changes, I’m able to see the save dialog. Before I made those changes, I was never seeing the save dialog.
I’m pretty sure the automatic download without prompting is the default in most browsers these days.
Is it possible for the mechanism to distinguish which Tiddlywiki file it’s associated with? In other words, it is possible to use this plugin to run several different Tiddlywiki files from the same browser (different tabs)? Thanks!!
The core browser storage plugin supports this but only if the tiddlywiki file is hosted at different urls. The plugin will use a different prefix in the browser storage depending on the url. For file:/// urls that is easy…just have multiple copies at different file locations.
The online wiki at My TiddlyWiki — a non-linear personal web notebook resides at just a single path, so just a single instance is supported.
However, with firefox you can workaround that limitation using the built-in “container tabs” feature (it can be enabled in the settings). With this you can open the same site in two different tabs with each tab in a different “container”. Each container has its own, isolated browser storage.
I use this for testing when I deploy new code to My TiddlyWiki — a non-linear personal web notebook. One container tab I always leave fresh so I can see what the blank-slate instance looks like. The other I have a bunch of plugins installed and other tiddler changes so I can see what it looks like for an “in-use” wiki.
The same could be achieved via separate browser profiles, but container tabs are easier to manage.
1 Like
Today I tried the demo and played with different features! It works amazing! One use case for me is with Edge/Chrome with memory saver turned on!
1 Like
I forgot to mention, any feedback related to the above pending pull request is welcome. Visit this tiddler:
browser storage settings
You will see something like this:
Prevent browser from evicting local storage
Permission for local storage persistence: not requested yet
The first time a tiddler is saved to local storage a request will be made to prevent automatic eviction of local storage for this site. This means the data will not be cleared unless the user manually clears it.
Old browsers may not support this feature. New browsers might not support the feature if the wiki is hosted on a non-localhost unencrypted http connection.
Some browsers will explicitly prompt the user for permission. Other browsers may automatically grant or deny the request based on site usage or based on whether the site is bookmarked.
The “not requested yet” will change to “granted” or “denied” after you’ve saved a tiddler.
As I have done with automatic window names we could at some point extend the local storage to follow the following steps to “name the local storage”
- Use the domain for http: and https: eg tiddlywiki.com
- If a folder is included in the path use that tiddlywiki.com-folder
- If file is uses construct the local storage address with the filename and/or folder name(s) mywiki.html or folder\mywiki
- Like wise if the filename is index.html
In the above other file based wikis can gain access to the same local storage but at least they will not accidently share the one file local storage.
The web browser maintains local storage per-domain. Within a domain, the core browser storage plugin already “names the local storage” by prefixing the keys with the pathname part of the url:
// Compute our prefix for local storage keys
var prefix = "tw5#" + window.location.pathname + "#";
This functionality is already present in the plugin.
Yes, I just discovered this myself, so its working well already. I am building a working example of the ideas I mentioned earlier and will share back.
The file name management and backup buttons work in progress.