Saving Tiddlers with Date-Prefixed Filenames in Node.js TiddlyWiki

[syrte]

Hi everyone,

I want to save tiddlers in the latest Node.js TiddlyWiki with filenames that include the creation date, e.g., 2025-11-07-My Note.tid, while keeping the tiddler title unchanged.

I asked GPT for help, but it wasn’t able to provide a working solution. I also searched online but couldn’t find anything. Does anyone know how to do this?

I understand that I should modify $:/config/FileSystemPaths. I tried something like this (and many variants) but it didn’t work:

[is[system]removeprefix[$:/]addprefix[_system/]]
[has[draft.of]addprefix[_draft/]]
[is[image]addprefix[image/]]
[!is[system]!is[image]!has[draft.of]addprefix[get[created]format:date[YYYY-0MM-0DD]]]

Thanks a lot!

[syrte]

These two posts might be helpful. I will check them in details later.

• Fully Automating TiddlyWiki Save Path Management - #4 by dongrentianyu
• Wiki with folder hierarchy

And this post is particularly relavant

• Add creation date to file name - #3 by kebnekaise

[syrte]

I belive the solution from Add creation date to file name - #6 by EricShulman

[!is[system]get[created]] [get[title]lowercase[]split[ ]] +[join[_]]

is very close to what I want.
The problem is how to get 20251107_new_tidder_2.tid instead of 20251107044358937_new_tidder_2.tid

[syrte]

This is almost what I want

[!is[system]get[created]format:date[YYYY-0MM-0DD]] [get[title]] +[join[ ]]

But I still don’t understand why the other filers don’t need get[title] manually, e.g.,

[is[system]removeprefix[$:/]addprefix[_system/]]
[has[draft.of]addprefix[_draft/]]
[is[image]addprefix[image/]]

[wiki_user]

tiddler titles are the basic unit of tw

filters
eg

[all[]]

return one or more title('s)

the filter for your case is
doing

[ get&format-date ] [get-title] +[join[]]

joining the result of two filters
which returns a new title

afaik

[wiki_user]

@syrte

But I still don’t understand why the other filers don’t need get[title] manually,

serendipitously i just read

.Working with lists in TiddlyWiki - #14 by etardiff

this

@etardiff

I find it difficult to draw a hard line between title lists and strings: to include more than one string/title in a stored variable, you have to insert spaces (and bounding brackets as needed), thereby converting your list of strings into… a new, longer string. Essentially, a title list only exists as a collection of discrete strings (rather than a single string than can be converted to smaller strings) when it appears in the context of a filter — and a filter like GettingStarted [[Discover TiddlyWiki]] Upgrading is really a shortcut for the series of filter runs [title[GettingStarted]] [title[Discover TiddlyWiki]] [title[Upgrading]].

which is/might be more clearly articulated ! confusion!! on the subject of titles / filters
ect…

… than can be provided by automated means

how insightful!!!
@etardiff thanks!

[etardiff]

@syrte

I still don’t understand why the other filters don’t need get[title] manually

Tiddler titles are the default output of most filters that work with the set of tiddlers in your wiki, so adding get[title] to the end of a filter string would be redundant. Indeed, get exists to return field values other than the title, as you can see in your filter:

@syrte

[!is[system]get[created]...]

[!is[system]] checks that each input title (typically <<currentTiddler>> in a subfilter, or all[tiddlers] otherwise) is not a system tiddler, and returns any tiddler titles that pass this check unchanged. To get the values of the created field of these tiddlers rather than the title values, we need to add get[created].

[syrte]

@wiki_user @etardiff Thanks for the clarification!
BTW, my initial attempt [addprefix[get[created]format:date[YYYY-0MM-0DD]]] does not work, because we can not use embedded filters?

[tw-FRed]

As a rule of thumb, you can’t nest brackets more than 2 levels deep in filters.

This is valid filter syntax:

[[myTiddlerTitle]]
[all[tiddlers]has[created]]
[<currentTiddler>get[created]]

But NOT this:

[addprefix[get[created]format:date[YYYY-0MM-0DD]]]
              ^------ third opening bracket not allowed

Hope this helps,

Fred

[TW_Tones]

@syrte

embedded filters?

A form of this is available using the subfilter operator, where the subfilter is in a variable or field, but in truth various filter runs can effectively do the same.

think of filters as passing lists, typically from one filter operator to another, it helps me.

[pmario]

Hi syrte,

Edit. It actually is possible to redefine the path and the filename using a filter expression. I only used it to define paths. Hence the wrong info in the “old post”

old post

Currently it is not possible to do what you desire. The $:/config/FileSystemPaths configuration can only define the directory to save tiddlers. The files are still named using the sanitised tiddler title.

While TW itself is able to handle filenames that are different to tiddler titles, there is no configuration at the moment, that would allow us to do so.

I’ll create a GitHub issue, as a feature request, but there is no promise, that someone will actually implement it in the near future.

The main problem here is, that it is hard to detect naming conflicts. There is a risk, that filter configurations, that define tiddler titles, will create the same file-name.

The risk is low if you use a date prefix, as you suggested, but the TW core has to work for all users. Also for those, who do not use a date prefix. There is a higher chance that “we” will overwrite files.

Which results in data-loss. Data loss is the worst thing that can happen in TW. So we will need to avoid that at all cost.

regards
Mario

[syrte]

Thanks for your warmhearted help, @pmario !
I should point out that $:/config/FileSystemPaths actually affects the file path, including the file name.

With this filter,

[!is[system]get[created]format:date[YYYY/YYYY-0MM-0DD]] [get[title]] +[join[ ]]

I do get files stored with paths like 2025/2025-11-06 My Note.tid.

[pmario]

@syrte

I do get files stored with paths like 2025/2025-11-06 My Note.tid.

You are right. I only used it to create paths. … So it seems it already works as intended. I’ll need to update my first post.