Could the browserstorage help avoid users loosing data

I think this is also hard-coded into the javascript. The tiddler $:/plugins/tiddlywiki/browser-storage/rawmarkup.js has this code:

    // Make sure that all the tiddlers we've loaded are marked as dirty at startup
    Array.prototype.push.apply($tw.boot.preloadDirty,log);

Where log contains the list of tiddlers which were loaded from local storage.

You could try commenting out that line and see if it helps. I didn’t test it.

Hi @btheado,
Thank you!
I do not know whether this does what I want to happen:
I guess this sets the Tiddlers imported form the browserstorage to a clean state.
I want to deavtivate completely the “you have unsaved changes” message if browserstorage is on…

Hi Mat, hie everybody… I will do so after getting some positive feedback on the usability.

In effect as I said it is a user-fallback-saving-solution, and for users it is now easier to choose what to add, what to keep and what to get rid of off in the browserstorage.

If you are the admin who saves to the server you still should be carefull activating this because of the risc of nagging ghosttiddlers of previous versions, when you were at a different computer meanwhile.

Folks and @JanJo I have returned from time in the bush and hope to progress this a little further. One reason is to package and document a firm solution to avoid difficulties when revisited in the future.

Some notes;

  • Separately from local storage it is important to note tiddlywiki is retained in browser memory just by loading it once, you can go offline and it will still be there, your changes will be retained.
    • For example load a node wiki (without external or skinny tiddlers and loose connection with the server
    • This will not necessarily retain anything if you close the tab and of course you can’t save.
  • I have some dirty indicator tools, one allows a bookmarklet to reset the indicator. This could easily be made an action widget by a javascript plugin author.
  • I can confirm setting $:/config/SaverFilter to “-[all[]]” will stop the dirty indicator being thrown, and local storage will still save changes. I am yet to confirm when we need to do this without forcing a reload but if the aforementioned action widget was available not reload is needed.
    • The wiki owner with save privilege’s will need to reset this to commit protect from loss.
  • It would be wise to load the wiki in a tab with a target name, and bookmark this such that subsequent opening of the site will always open in the save tab.

Additional features

  • Suitable backup and restore changes tool for read only users
    • This includes how to support users if they load a site they did have backups for, but it is lost. We need to prompt them to look for a backup to restore from if it exists, to support this I believe a smart bookmarklet can be used and store the backup location.
  • Suitable “send changes” tool so a local storage only user can send changes for inclusion in the underlying main wiki (Mediated or automatic).
    • Imagine if the changes can be saved to a username folder and the master user can see/import them.

Reset dirty indicator below, create bookmark and put the following in the URL

javascript:(function(){ $tw.saverHandler.numChanges = 0; $tw.saverHandler.updateDirtyStatus(); })();

Hi Tony! Yes that is the aim. I have a workflow for this which I am just testing with a course. It still needs too many clicks. When intensive collaboration startet it was hard to keep an overview over the contents of the folder.
I have been searching for a while for a demo that @saqimtiaz posted on a WebDAV solution which was much more elegant, but I cannot find it anymore.

@JanJo I have continued in creative mode and have being exploring opportunities to help with this form of collaborative tiddlywiki use. I have a number of leads that could make this easy, and reliable for naive users.

This gets somewhat complex very quickly because tiddlywiki presents a lot of opportunities, and of course understanding what users can do or understand, is a dark art rather than a science. Even more so when you include consideration of different browsers, their features/settings and the Operating system.

I am confident there is sufficient opportunity to solve this, for example I have found a way to convert a tiddlywiki found at a URL to generate a unique filename for saving changes. We can add user name into this, to handle a full class of submissions, but then we need to “enforce” the provision of user name.

Do let me know where too many clicks are needed, I imagine I can simplify the process with some of the tricks I have acquired.

Hi Tony, the problem is formulated in this thread.

I just had a look at my import php which has quite a lot of other functions integrated. I think I will build a different approach from scratch that works with dragging.

1 Like

@JanJo I can’t answer that question however can you not go back one level and have the wiki text trigger the http request and then handled the data?

Setup
call httprequest
handle retrieved data

Sounds really interesting, keep up the good work.

Hi @TW_Tones , okay…
If you are willing to go that way
here is the next step of the journey in the php-tutorial:

1 Like

A Trick I have being using is to add an action to the download button that I make, that copies the full path and filename into the clipboard. Once my save as dialogue is presented (Windows 11) ctrl-v pastes the full path and filename and I hit save, it can be done similarly to open a file.

As long as we know the full path and filename (stored in tiddlywiki) we can introduce more interactivity with the local machine.

I wonder if we had an agreed file path eg; \tiddlywiki that we use by default?