[tw5] The browser-storage plugin

Google Group (Read Only)
#1

Charlie’s post on browser storage (https://groups.google.com/g/tiddlywiki/c/l-1YLy0xpJo/m/mreI115qAgAJ) prompted me to post a reminder about the official browser-storage plugin. Charlie is exploring many interesting use cases for browser storage, but that particular post covers the same functionality as the browser-storage plugin.

The browser-storage plugin automatically writes any modified tiddlers to browser storage. It only writes tiddlers that match a filter, which one can set to [all[]] to save all tiddlers, or something like [prefix[$:/state/]] -[prefix[$:/state/popup/]] to just save state tiddlers.

At startup, the browser-storage plugin reads tiddlers from local storage. Any tiddlers that are identical to those built into the file are deleted from local storage. Once the wiki is up and running, any tiddler changes are written straight to local storage.

To try it out:

  1. Visit https://tiddlywiki.com/editions/full/#%24%3A%2Fplugins%2Ftiddlywiki%2Fbrowser-storage
  2. Click on the “settings” tab of the plugin
  3. Scroll down to the heading “Save Filter”, and change it to “[all[]]”
  4. Create or modify some tiddlers
  5. Refresh the page
  6. Observe how the changes are restored
    As discussed in the plugin readme, there are some gotchas with browser storage, but it can still be useful in many situations.

Best wishes

Jeremy.

1 Like
#2

It would be some nice if somebody put together a video and/or some documentation on how somebody can plop a TiddlyWiki out there on the web, and set it up so that viewers can set their own viewing preferences for that TiddlyWiki, such that every time he/she visits that TiddlyWiki, it always displays with their preferences.

And whenever the author of that TiddlyWiki publishes a new version with updated content, viewers still have their preferences working.

That would be pretty cool.

#3

Out of the box, the browser-storage plugin saves $:/state/ tiddlers (apart from $:/state/temp/ tiddlers) and thus most of the UI state. There’s no configuration beyond installing the plugin and restarting.

To make it save all configuration such as which toolbar buttons are hidden would require changing the “save filter” to:

[prefix[$:/config/]] [prefix[$:/state/]] -[prefix[$:/state/popup/]]

Best wishes

Jeremy

1 Like
#4

Quite awesome, except for one thing: it is opt-in by default, right?

Within the boundaries of the filter, it is an all-in / all-out option, by default all-in for the viewer of that TiddlyWiki ?

I cannot stand “opt-in” by default, leaving the user with the manual effort of opting out, whatever/wherever/whenever it is.

The thing I’m setting up, it is “opt-out” by default, and selective opt-in for every little thing a viewer wants. A manual step that could offer an option of full-auto if I ever add that in.

If there is a way to do that kind of thing with the plug-in, that would be a really wonderful thing to document.

#5

Hi Charlie

Quite awesome, except for one thing: it is opt-in by default, right?

I’m not sure what you mean. If you referring to the fact that on the demo that I linked the browser-storage plugin is activated by default, it is possible to leave it set disabled, and expose a checkbox or something for the user to enable it for themselves.

Best wishes

Jeremy

#6

Oh, I mean somebody else’s TiddlyWiki putting things in my local storage without my “yes, I agree” (i.e. “yes, I opt-in”) consent.

#7

Oh, I mean somebody else’s TiddlyWiki putting things in my local storage without my “yes, I agree” (i.e. “yes, I opt-in”) consent.

That’s hard to prevent in general: HTML pages don’t need user permission to write to local storage.

In the case of the browser-storage plugin, steps are taken to separate the data from wikis on different file URIs (the key names used to store the tiddlers are qualified with the location of the file).

Best wishes

Jeremy

1 Like
#8

Then that will be the glaring difference between my work and the plugin.

Well, the plugin is really for the benefit of a TiddlyWiki’s owner. What I am doing is for the benefit of the TiddlyWiki viewers.

Something like that. It is a moving target …

#9

Hi Charlie,

Then that will be the glaring difference between my work and the plugin.

I still don’t understand what you meant. What is the glaring difference?

Well, the plugin is really for the benefit of a TiddlyWiki’s owner. What I am doing is for the benefit of the TiddlyWiki viewers.

Are you referring to your idea of using local storage to transfer data between wikis in the same browser?

Best wishes

Jeremy

1 Like
#10

Well, more so a wiggling target than moving. Or gently swaying …

#11

Arg. Now I have “Cloudy with a chance of meatballs” stuck in my head…

#12

The glaring difference is the plug-in is opt-in, by default, to local storage of everything intended for local storage by the TiddlyWiki author. Opt-out is manual and is opt-out of everything intended for local storage.

What I am doing is opt-out by default, and opt-in local storage for only those tiddlers a viewer is interested in having stored locally, and having the choice each session of disregarding any tiddler changes one does not want remembered for the next session.

Nothing to do with inter-wiki communications/sharing.

#13

Arg, I mean the plug-in is opt-in and opt-out for all tiddlers defined by the filter. By default, the plug-in itself can be set to either on or off by the author for all viewers. Maybe the setting to turn the plug-in on/off could be one of the tiddlers that can get saved to local storage to let users decide the default for every time he/she visits a TiddlyWiki.

Regardless, the very DNA of what I’m creating is local storage not happening by default, a certain list of tiddlers each individually allowing local storage saving or not, and eventually something that says “yes, or no, to every tiddler in the set” in addition to tiddler specific within the set.

Something like that.