Update a timestamp tiddler when a wiki is saved

[Jermolene]

As discussed on the mailing list, it would be useful if a system tiddler were automatically updated with the date and time of the last save.

[AnthonyMuscio]

And display the result in $:/ControlPanel > Info > Basics and/or $:/ControlPanel > Saving > General

[hchaase]

Yes, this would be useful! To see when the last save was done I quite frequently check the more>recent tab.

I second the suggestion in the malign list: "I can envision that timestamp being transcluded in "Tool" right under the wiki version number AND in Control Panel along with number of tiddler & overwritten shadows."

extra feature: it could be handy (though not needed) if the modification date (as presented above) was a link to the last edited tiddler.

edge case: what would happen when you turn timestamp off and save a tiddler (e.g. to correct spelling), would that change the timestamp?

[Jermolene]

edge case: what would happen when you turn timestamp off and save a tiddler (e.g. to correct spelling), would that change the timestamp?

I would envisage the timestamp being generated at the instant of saving, independent of the state of the tiddler store.

it could be handy (though not needed) if the modification date (as presented above) was a link to the last edited tiddler.

That would be possible, but I'm not sure very obvious?

[pesho-ivanov]

This feature can also be useful for automatic spotting overwriting from an older wiki state (thus losing data).

An even simpler approach would be keeping a consecutive "version number" instead/alongside with the timestamp.

[AnthonyMuscio]

Is it possible to make this happen?, it will be a complement to the newish $:/info/startup-timestamp because we can actually identify wikis opened, have changes and when and last saved.

\function last-modified() [all[tiddlers]get[modified]!sort[]first[]format:date[0hh:0mm DDD, DD. MMM YYYY]]

• This is a function that determines the last modified tiddler (only) but I wonder if it would be better set somewhere in the core for performance reasons?
• The question remains what if I change a system tiddler?

The key issues are in my mind;

• Will it only update if the save is successful?
  • If a save was successful then we can determine the wiki is not read only
  • perhaps wikis could be in a read only mode until proof it can be saved (not downloaded)
• Should it indicate a save when is was actually downloaded?
  • perhaps this should be indicated differently?
• Will it do so for both manual and automatic saves?
• The relationship to the local storage plugin

The reason I returned was I was just creating a wiki info panel containing useful information to understand the status or disposition of a wiki. It seems to me something the core should provide thus giving designers the Ability to make use of this information.

[saqimtiaz]

Related to #6684 and #7131

In particular this comment from Jeremy about possible ways forward: https://github.com/Jermolene/TiddlyWiki5/pull/7131#issuecomment-1377988449

[Jermolene]

Hi @AnthonyMuscio the fundamental challenge that we face is that TiddlyWiki cannot always tell whether a save was successful. In particular, there is no way to determine whether the default fallback download saver succeeded or not.

Therefore the approach that I suggested to @pmario and that he is pursuing in #7953 is subtle: the timestamp is injected into the saved file, but is not included in the wiki doing the save. I think that might preclude some of the scenarios that you have outlined.

[AnthonyMuscio]

I think that might preclude some of the scenarios that you have outlined.

I expected this to be the case, but especially with downloads, rather than savers, but lets assume if a save fails, the user becomes aware of it, from the browser if not the saver modules. This is when they may need to address a problem.

• Mario's method also has merit, so I am not disputing that.

There would still be a great deal of utility at least knowing in the current live wiki the last time a manual or automatic save was attempted. Perhaps the current wiki could just log the time a save trigger was initiated, not implying a successful save. eg; $:/info/last-save-triggered

• Basically there is value in capturing this data and designer will need take account of the limitations discussed above
• At the moment we do not even have access to this information from automatic or manual saves.

An example where this may prove useful is when its necessary to turn off automatic save due to the wiki size, that with some of Erics timer triggers, a wiki containing unsaved changes could just save after an hour of no activity. Not leaving unsaved changes in the browser. It could do this by reference to $:/info/last-save-triggered date/time stamp.

• But there other possibilities.
• It may make sense to use a $:/temp/last-save-triggered tiddler.

[pmario]

There would still be a great deal of utility at least knowing in the current live wiki the last time a manual or automatic save was attempted.

Since every user interaction with TW will hit the wiki-store, the modified stamp of these tiddlers will give you that info.

• If you want to know the time of the last user activity you only need to use this filter: [has[modified]!sort[modified]limit[1]get[modified]]

• If you want to know, when a draft-tiddler was modified you can use: [has[modified]!is[system]!sort[modified]limit[1]get[modified]]

• If you want to know when the last tiddler save happened use: [has[modified]!is[system]!is[draft]!sort[modified]limit[1]get[modified]]

So imo that's all the infos you requested in the last post.

[AnthonyMuscio]

With respect that is not what I want. I want a timestamp set each time an automatic or manual save takes place with (not possible) or without it knowing if it were successful.

• If it fails to save we usually get some other kind of message
• If the save results in a download (not a save) I don't want this to count if possible, because the wiki in memory has not being saved only "exported".

[Jermolene]

Hi @AnthonyMusciothe semantics you are asking for are getting a bit specific to the scenarios that you are experimenting with. I don't think your current proposal is universal enough for the core.

I think then that the best way to address your needs might be to add support for actions that are automatically invoked before every save. That would enable you to experiment further, and would be useful new capability for others.

[saqimtiaz]

@Jermolene as you pointed out in https://github.com/Jermolene/TiddlyWiki5/pull/7131#issuecomment-1377988449 adding support for pre-save actions could be problematic because of the possibility that the modification to the tiddler store triggers another save.

[pmario]

Tony wrote

With respect that is not what I want. I want a timestamp set each time an automatic or manual save takes place with (not possible) or without it knowing if it were successful.

That's exactly what this filter does

• If you want to know when the last tiddler save happened use: [has[modified]!is[system]!is[draft]!sort[modified]limit[1]get[modified]]

Jeremy wrote

I think then that the best way to address your needs might be to add support for actions that are automatically invoked before every save. That would enable you to experiment further, and would be useful new capability for others.

I did explore the possibilities with actions activated right before a save happens at: Record state saving timestamp #7131

It turns out, that this mechanism is super brittle and can easily lead to endless save-loops if done wrong. That's why I did close the PR and did create a new one, which injects last-save-timestamp into the save-file, without modifying the current wiki store.

[Jermolene]

Thanks @saqimtiaz @pmario I had forgotten our earlier discussions and experiments about this. I do wonder if it might be worth investigating the infinite loop issue.

[pmario]

[. . .] I do wonder if it might be worth investigating the infinite loop issue.

The very first version of the closed PR was hardcoded, so Saq suggested a more flexible version. But the user tagged actions can cause endless loops very easily.

So it definitely was a problem with the closed PR.

[AnthonyMuscio]

On reflection on this discussion, and for clarity, I thought I would try and make this clearer.

I am not talking about when we save a tiddler, with the done button. This will set a modified date (if timestamps are on).

• I was looking for a timestamp which tells us when a last attempt to commit to disk occurred.

If the wiki has autosave ON, in most cases hitting done on a tiddler saves the tiddler and triggers a save. So in this case the last modified date is a proxy for the last saved, however if autosave is off, it is not a proxy for the last save.

If the wiki has autosave OFF. Hitting done on any tiddler it is "saved only within this browser". In this case last modified is the "last unsaved change", and not a proxy for the last saved to disk.

Why may autosave be switched off or not working?,

• There is no working save mechanisium eg on TiddlyWiki.com
  • Go and look at tiddlywiki.com, autosave is on, there is no save mechanism, the last change makes the wiki dirty, but does not save
• If I have turned Autosave off
  • perhaps my wiki is too big to use autosave.
• I have local storage active and closed then reopened the wiki.
  • changes are saved to local storage, but not "committed to disk".
• There are also hybrid situations where this changes during use of the wiki, I was using autosave, now I disabled it, I turned off local storage...

I thought if when you hit the save button manually (and automatically for consistency), you can set the last save attempted time. Although I think this will occur if you select to download the wiki as well.

• I assumed we can tell the difference between using the download saver and other savers? If so (and if possible) don't set a save attempted when in fact a "default download mechanism" is used/done.
• Thus I thought lets us only update the last "save attempted date stamp" if any other saver was used, Manually or automatically.
  • Ideally we would do this only on a successful save, but I was happy just with an attempt (I assume the save occurred and if not the user got a save error message)
  • Although we could reset or delete the last successful save attempt time stamp, if a save fails, at least in memory.

Regardless of autosave on / off, a manual or automatic save occurred, or another action to save was a triggered, I thought when a save occurs (or is attempted) we could set a save attempted timestamp, then attempt a save.

• Of course if the save is successful the wiki in memory and on disk will contain the last attempted save time stamp, if it fails the file does not, but the browser does.

Why?

We can use this information to simple advise the user, or make use of the information to identify in wiki's in the browser memory - last loaded loaded, last modified (tiddler) and last committed (attempted) to disk, even if we have local storage active.

Using this information

• Possibly even trigger an attempt to save automatically after 2 hours of inactivity.
• It may even be possible to clear the current user ID, change the wiki to lock as read only and save. Thus releasing the wiki for another serial editor to use. To continue they have to reload.

I really have done my best to explain, and perhaps to address what seems to be misunderstandings, on my part or others.

[pmario]

If the wiki has autosave ON, in most cases hitting done on a tiddler saves the tiddler and triggers a save. So in this case the last modified date is a proxy for the last saved, however if autosave is off, it is not a proxy for the last save.

That's exactly, what PR #7953 does. Whenever a single file wiki is created, it injects 2 tiddlers into the wiki store. Those 2 tiddlers are only available with a successful save attempt. Since they are only stored to the file. They will be seen by the user after the file is reloaded.

With the very first Record state saving timestamp https://github.com/Jermolene/TiddlyWiki5/pull/7131 we did allow the user to trigger custom pre-save actions. It turned out that this approach is absolutely brittle and with a certainty of 100% will cause endless saving loops. It was extremely hard for me to get it right. That's why we did abandon that approach.

The initial commits of #7131 created hardcoded pre-save timestamps, that where part of the wiki store. (I could probably re-activate that one). But I'm not sure, if we can create it as a 3rd party plugin. The problem here is, that those tiddlers have no real value, since we do not get any info from the browser, if the file was really saved to disk. So this approach will give the user a false sense of security, while they still can loose data. -- IMO that's not really what we want.

If autosave is off, the last tiddler modified timestamp, has the same "non value" as the pre-save timestamps, I did with the hardcoded timestamp tiddlers in #7131

[AnthonyMuscio]

Thanks @pmario Let me address your nice summary by each paragraph

1. My point was " I want even the last attempted save to be available to the current wiki session, so I can interrogate it."

Since they are only stored to the file. They will be seen by the user after the file is reloaded.

2. I too thought "custom pre-save actions" would be nice;

#7131 we did allow the user to trigger custom pre-save actions ... is absolutely brittle

• So I would be happy to do without custom pre-save actions. Let us have as originality requested by me, a single, specific, pre-save feature (no action), to set a "save attempted" time stamp.
• If possible, set a saved successful timestamp, in the current browser session.

3. I gathered as much from the discussions that;

The problem here is, that those tiddlers have no real value, since we do not get any info from the browser

• This is why I asked if we could set a "save attempted timestamp". This is needed because it is hard to identify if a save is generated automatically, manually or by an action/save wiki message.

So this approach will give the user a false sense of security, while they still can loose data. -- IMO that's not really what we want.

• Forget sense of security, its information we "need" successful or not. We can;
  • Name it save "attempted" showing its not guaranteed
  • Include the the fact it is uncertain in the documentation
  • Don't promote its use, just document it for people implementing features that need this information.

4. I know the following, and the solution I suggested, allows us to avoid the ambiguity in using this proxy (which is unrelated to saving) in some cases and not others. For example with manual or triggered save attempts (not automatic).

If autosave is off, the last tiddler modified timestamp

In closing

it would be suitable if such a "save attempted" timestamp was under the $:/info/ namespace and even appear as a shadow, perhaps $:/info/last-save-attempt-timestamp.

I do not know enough to delve into the saver mechanisms but I am surprised;

• If they cant "log" when they are activated
  • Perhaps even stating which saver mechanism was ultimately used
• I also understand, but are disappointed, that browsers don't at least return a success, fail or cancelled indication on save.

[AnthonyMuscio]

I was just testing the actions on a button and used the action log widget.

I saw the console log display this;

saver-handler: Saving wiki with method autosave through saver tiddlyfox $:/core/modules/utils/logger.js:53:26
Timimi: Sending native message [background.js:16:11](moz-extension://253db23c-cc5f-453e-a349-eff2b4345215/background.js)
Message ID is tiddlywiki-save-file-response-15 [content-script.js:123:15](moz-extension://253db23c-cc5f-453e-a349-eff2b4345215/content-script.js)
Timimi: Native Host Responded without errors [background.js:2:11](moz-extension://253db23c-cc5f-453e-a349-eff2b4345215/background.js)

This means at least the console log knows the wiki used the tiddlyfox save, used Timimi and Timimi: Native Host Responded without errors and from this we can get the times.

• Why don't we just ensure this same information is available to the TiddlyWiki designer?
• Including which save method was used.

I just used the download saver and it returned

saver-handler: Saving wiki with method save through saver download $:/core/modules/utils/logger.js:53:26

• This proves in my mind it would be trivial to set a last save attempted, and by which method. But in the case of savers (rather than the down load saver), even indicate even indicate a successful save.
• I don't want the download saver to count as a save, as it is in fact a clone, and what remains in the browser is not saved.
  • But it would be great to know when a download is done.