Emergency JSON export looks like is not TiddlyWiki-compliant

, , ,
#1

I’ve experienced a hard-crash recently and the only option given was to export all tiddlers in JSON.

It seems like the exported JSON does not fully conform to what TiddlyWiki’s import functionality expects. The result is that the tags field gets silently dropped on import:

Emergency export JSON format sample

[
    {
        "created": "2026-01-07T07:47:26.956Z",
        "text": "blah blah",
        "tags": [
            "tagA",
            "tagB"
        ],
        "title": "Tiddler Name",
        "modified": "2026-01-11T16:01:01.976Z"
    }
]

Regular export for single tiddler sample

[
    {
        "created": "20260101000000000",
        "text": "blah blah",
        "tags": "tagA tagB",
        "title": "Tiddler Name",
        "modified": "20260101000000000",
    }
]

The created and modified fields are also differently formated but this was not so impactful in my case. The tags getting silently dropped meant that most of my coded logic and all of the ViewTemplates where not applied.

#2

This looks like a dump of the internal storage format. I’m on my mobile device right now, but when I’m back on a computer, I can write a quick script to allow you to convert that into a format you can import back into TW.

Please let me know if you’re comfortable with the command line and if you have NodeJS installed. (It’s quicker for me to write if you do, but if not, I’m sure I can figure something out.)

1 Like
#3

Thank you for your kind offer. I fixed the JSON file with a combination of regex and a few VSCode extensions. I managed to re-import it and everything ended up as it should.

I was just expecting that the exported JSON would be immediately importable into a fresh TW.

It looks like that to me too. As far as the tags field is concerned, since both formats (array of strings vs single space delimited string) are valid JSON, maybe they should both be handled properly by the import functionality?

#4

Great!

It would be nice. It would be easy enough to write a transformation to do that, but I’m not sure that we could count on having enough memory free to run it. That code could well be running in a very resource-limited environment.

I think valid imports must have string field values. If you tried to import {"title": "X", "count": 42}, the count property would be skipped because it’s a number rather than the string "42". I would love it if we could expand imports as you suggest, But there would be some interesting questions to answer before doing that. For instance, should a boolean property get imported as "yes"/"no". And would we export other list fields as arrays as we do with "tags"? (For that matter, do we do so already?). Are there other date fields that would require conversion besides "created" and "modified"?

1 Like