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 were 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
#5

I would just add here once imported there is room to reformat tiddlers based on additional rules. Changing the import format standards should be only done if there are deterministic reasons to do so.

#6

The idea here would be not to change how any current imports work, but only to expand to allow certain imports we cannot currently manage.

This should be entirely backward compatible, except possibly for one small edge case I cannot currently test, but will try later: if we can right now import a tiddler with a created or modified field that has had a value like 2026-01-13T22:15:33.042Z, and that string is retained intact for the field, then this idea would break that, as it would end up with a standard date field.

Other than that, everything should just work.

But I have no ideas of anyone would want it, or if the core team would approve.

#7

Tested. It’s not retained. If we import this JSON tiddler:

{"title": "My Test", "tags": "Import Test", "created": "2026-01-05T08:48:17.000Z"}

Then [[My Test]get[created]] yields 20260101000000000. So that’s not an issue. I suppose it is theoretically still backward incompatible, if you are depending upon an unrecognized date format doing this form of “best match” for the date, then I guess this change would break your expectations, but that’s not a case I would ever worry about.

#8

I’m also struggeling with the Import JSON tids with this sort of structure in my ai-adapter plugin. It would be good, if the Import-Tools of TW were more flexible to grasp variants

#9

The code that generates the JSON for download in error scenarios try to be minimal to ensure that the JSON can successfully be exported, and looks like this:

			$tw.wiki.each(function(tiddler,title) {
				tiddlers.push(tiddler.fields);
			});
			var link = dm("a"),
				text = JSON.stringify(tiddlers);

I wonder if we could try to correctly export the JSON and fallback to the current behaviour if that fails:

				$tw.wiki.each(function(tiddler,title) {
					try {
						tiddlers.push(tiddler.getFieldString());
					} catch (e) {
						tiddlers.push(tiddler.fields);
					}
				});
				var link = dm("a"),
					text = JSON.stringify(tiddlers);
2 Likes