Force re-save of tiddlers whose file system path has changed

[Soren Bjornstad]

Some time ago I tweaked the $:/config/FileSystemPaths in one of my wikis to place tiddlers into some different folders based on tags, as described here. However, I haven't modified all of these tiddlers yet, so months later some of them are still in the default location, making the division not all that helpful since it's difficult to know which location each item is in.

Is there a way I can get TiddlyWiki to re-save all my tiddlers into the location they would be placed today, in bulk (ideally without updating their timestamps)? I could rig up a shell script, but that feels like it could be a lot of work.

[Joshua Fontany]

Hi Soren,

I wrote most of the recent Node file-handling logic.

I found the easiest way to "touch" a batch of tiddlers in order to force a re-save is to $action-deletefield a NON-EXISTANT field from within a $list (triggered by a $button).

This forces the tw core to re-save a tiddler over the existing one (even tho its the same) & this triggers the Sync mechanism.

(You can also use this to "unpack" shadow tiddlers from within plugins, forcing a "normal" tiddler that is the same as the shadow-copy.)

Best,
Joshua F

[Soren Bjornstad]

Thanks Joshua, this worked great!

For anyone else needing this, I switched off timestamps, then created a tiddler containing the following button:

<$button>

Do The Thing

<$list filter="[is[tiddler]]">

<$action-deletefield afieldthatdoesntexist="" />

</$list>

</$button>

Clicked the button, then turned timestamps back on, and all the changes showed up in Git as expected.

(For whatever reason the $action-deletefield form with $field="afieldthatdoesntexist" did not do anything when I clicked the button. Not sure what was up with that.)

[PMario]

Hi Soren, 

IMO your code is a bit "dangerous". If copy pasted, it will modify the modified field, if users don't read everything carefully.

I did create a tiddler that can be saved and imported, which should be less error prone.

The code is more complex, but it shouldn't do anything if only copy pasted and if users don't read the info.

 - It reads the active $:/config/TimestampDisable info and makes a backup

 - It sets TimestampDisable to "yes"

 - It touches ever tiddler tagged XXXXX    <- This value needs to be adjusted by the user

 - It sets TimestampDisable back to it's original value

have fun!

mario

[Soren Bjornstad]

On Tuesday, June 15, 2021 at 4:21:23 AM UTC-5 PMario wrote:

Hi Soren, 

IMO your code is a bit "dangerous". If copy pasted, it will modify the modified field, if users don't read everything carefully.

Fair enough, but nobody should ever try something like this without a backup anyway!

[PMario]

Sure. ... But I write it down, just to be sure.

-m