What? Is there a magic setting? When I tried it, I seemed to hit the ceiling at around 5 megs. 2Gbyte would be amazing.
Edit: TW’s own docs suggest 5 to 10 MB: https://tiddlywiki.com/#BrowserStorage%20Plugin
Or are we talking about something else?
Well, another feature that could help with that could be a timestamp -like mechanism?
Something I used to do was instead of setting an actual subtitle, I would have the modification date of the last updated tiddler inserted.
It would look something like “Justin’s TiddlyWiki – Last Updated: (YY/MM/DD@24HHMM of last modded tiddler)” in the browser address bar. Doesn’t prevent overwriting per say, but helped keep track of whichever was more up to date. I’m sure TiddlyHost has a mechanism in place to help with prevention of accidental overwriting, though I’m not certain of that.
I’m not sure if I still have that tidbit, sadly. Scratch that! TiddlyWiki has docs of something arguably better I think.
You can find it Here!
This has not being tested thoroughly or for a long time (if ever). There are other factors as well. This deserves some research.
Do you mean last saved timestamp ? like here [IDEA] Last saved timestamp and what it may enable · Issue #6684 · Jermolene/TiddlyWiki5 · GitHub
I haven’t seen this before, I’ll give it a quick read and let you know, but it sounds interesting.
I linked to a banner modification in tiddlywiki.com that had the behavior I had attempted to make way back when.
Edit: So, I’m not 100% I’ve read this all correctly but the premise of “Two identical tiddlywikis opened in two different tabs, without any modifications to either, how do you tell them apart” has me interested.
I would imagine the method of differentiating them is to use the time at which they were open, since in HH:MM:SS.mmm, there should be no way a user can open them both at the same exact milisecond.
Not sure how relevant that is to this specific discussion but a fun idea to play with!
TiddlyTools/Time/LastModified.js defines a macro <<lastmodified>> which returns the document.lastModified value and also supports a format parameter to apply TW Date Formatting codes to the macro output.
-
<<lastmodified>>
returns the browser-formatteddocument.lastModifiedvalue (e.g. “01/12/2023 18:21:18”) -
<<lastmodified "[UTC]YYYY0MM0DD0hh0mm0ss0XXX">>
returns a 17-digit TWCore system UTC datetime stamp (e.g., “20230113022118000”). Note thatdocument.lastModifiedtypically does NOT include milliseconds, which defaults to “000” in the output. -
<<lastmodified "DDD, MMM DDth YYYY at 0hh12:0mm:0ssam">>
returns a formatted datetime (e.g., “Thursday, January 12th 2023 at 06:21:18pm”)
Thus, rather than relying upon the timestamp of the last tiddler modified, you can use the above macro to report the actual datetime at which the file was saved or uploaded.
And, if the macro is not installed, you can use something like:
<$let modified={{{ [<lastmodified "[UTC]YYYY0MM0DD0hh0mm0ss0XXX">]
~[all[tiddlers]sort[modified]last[]get[modified]] }}}>
as fallback handling to get the modified timestamp value from the last tiddler that was modified, and then:
<$text text={{{ [<modified>format:date[DDD, MMM DDth YYYY at 0hh12:0mm:0ssam]] }}}/>
to format that timestamp value for display purposes.
enjoy,
-e
3 Likes
I just want to make an important point I think is often overlooked.
- Until a save occurs the local storage plugin ONLY stores changed tiddlers in local storage.
- As a result you can load a large wiki in the browser and with local storage active only those that match a configurable filter get stored in local storage.
- As soon as a save takes place and or the user exports their changes and turns off the Local storage the space is reclaimed.
- This means you would have to work very hard and operate off line, or import bulk content, before you will challenge available local storage.
I have always believed it would be possible to make TiddlyWiki robustly detachable/disconnected from where it is loaded and using local storage, IndexDB or PouchDB can remain safe in a device until reconnected.
- Since most people have some form of internet connection daily we should be able to safely run tiddlywiki on any device with a browser and no app’s needed.
I also want to point out many of us use many single file tiddlywikis from file: addresses thanks to Timimi. TiddlyWiki’s can be as common as word documents for some of us.
- Autosave is practical and almost unlimited.
1 Like
@Justin_H: this TiddlyWiki permalink you posted refers to “Corner ribbon”, as if it’s an official plugin, but there’s no official plugin by that name. It would be great to fix that loose end on Tiddlywiki.com – meanwhile, can anyone reconstruct whether that plugin just got renamed, or how else we can follow up on it?
1 Like
If we’re talking about newbies, let’s remember that they might drag in a huge image or two, without realizing that linking is wiser than swallowing… Also, student newbies could be working on a lab computer, where all sorts of things can interrupt those sessions or force a logout/login during which session data is automatically flushed. For students, I don’t see any other no-nonsense learning path besides tiddlyhost or similar cloud-based hosting, with auto-save.
I wish a mini-version of tiddlyspot’s old backup system were still possible, since it would be ideal to have something like a restore-from-recent option – in the event of unwise edits that mangle the interface or break basic functions.
This plugin was used with previous iterations of TW, now you can find something similar with the GitHub Fork Ribbon in the plugin library.
You can simply take the text of what I linked, remove the custom CSS in the divs, and add it to whatever you’d like, like I did by placing it in my subtitle.
1 Like
All good! My response was not so much a “How do I do this?” question; it was expressing concern that this thread points to a tiddler at TiddlyWiki.com, which in turn recommends a plugin that isn’t there (at least as named), which is a potential source of confusion.
Right!
Despite huge (kudos) efforts by @Mark_S and others to try to tame the tiger of TW resources into something one could pet, I still find TW, overall, a very FRAGMENTARY experience when you need to find relevant resources to address an aim.
The frustrating thing is I know a solution exists somewhere.
But how do I reliably find that somewhere?
Just an IMO, TT
3 posts were split to a new topic: I’m a software dev. Why does wikitext of all things give me so much trouble
If you follow the instructions in the link (Install the Plugin), and type “corner” into the Official Plugin’s search, you find:
GitHub Fork Ribbon: GitHub-inspired corner ribbon
About a dozen Official Plugins are searchable from the standard TiddlyWiki.com site, but not all of them (though they’re all documented once you install). I suppose this is just a matter of someone taking the time to make some public-facing docs.
1 Like
I think the original topic became a bit sidetracked but as for the topic of autosave, it is true users have grown to expect saving to “just work”. But it is possible to have data loss merely by using “Undo” and “Redo” over and over again, so users should come to expect unless explicitly saved they could experience data loss.
Another example would be if you were editing a page on Wikipedia and you refreshed the page you would lose all your progress.
I’m intrigued by the idea of using local storage somehow. I would imagine there might be a way to only store the changed tiddlers instead of the entire wiki since there are size limitations.
1 Like
I think that the Browser Storage addon save each tiddler independently, since there is a save filter:
I just tried it on FF. I only put in a handful of image files before I got the exceeded quota warning. So unless there’s some way to tell the browser to use the max amount possible, it doesn’t look very useful.
Edit: I think it is hitting a “soft” limit, which should result in a message allowing the user to OK the increased amounts. Possibly the plugin could be tweaked to bypass the soft limit.
- To be clear this is the current behaviour
For the limited inclusion of images I use I have never come across this problem, I will try and to replicate it,
Lets try and improve this
However if a wiki is intended to include media Image, Video and Audio beyond the occasional item then it is necessary to look at how its being hosted or served.
- Most modern media files are equal to or greater in size that the empty tiddlywiki.
- A single file wiki is a great feature of tiddlywiki but it is putting the whole site in one file.
- Using another host and linking or embedding media is often the best approach eg YouTube embeds
- There are great solutions available and one the way for server hosted TiddlyWikis from Bob to the File Uploads Plugin.
- Local files do not have a need to depend on Local Storage because the file system in local storage.
It is internet and intranet facing wikis where the Local Storage Plugin becomes more useful but this is also when other factors must be taken into account.
1 Like
I guess you can kill any Wiki that way. Perhaps it would be a good idea to add a warning if a media-file to be imported exceeds a certain size anyway - and that if users wish to continue adding such files it would be good practice to link them externally.
These were small images that I used so I didn’t have to spend all day creating tiddlers. The total size was probably less than 5 megs. This is well within TW’s abilities, even on small devices.
There is a soft limit and a hard limit with local storage. It appears to me that the local storage is throwing up its virtual hands when it hits the soft limit. When the soft limit is reached, the app/browser is supposed to verify with the user that they want to exceed the limits. But there is no dialog offered to the user.
I did the math. I managed to add 4.5mg of files before I hit the limit. This is a fraction of the 2Gig I should be able to add at the hard limit.