Re-embedding .meta files in their tiddlers

#1

I’ve done the following to my plugins, stylesheets and SVGs that had separate .meta files:

  • Copied the content of $__plugins_user_xyz.json.meta to the top of $__plugins_user_xyz.json
  • Deleted $__plugins_user_xyz.json.meta
  • Renamed $__plugins_user_xyz.json to $__plugins_user_xyz.tid

Everything still works as far as I can tell. Is there anything I need to worry about in having done this?

The story:

Like many other large companies, my employer, GigantiCorp, has some amazingly stupid rules.

As we’re planning to move all our GitLab Enterprise over to the larger GitHub Enterprise, I got a nasty surprise when it wouldn’t let me upload .meta files. It avoids all sorts of extensions. This one is listed because it is a “Visual Studio File Type”.

I will argue this at some point when I find the right people to talk to, and I’ll likely win. But this was my temporary hack. Clearly it won’t work for binary formats like PNGs. But I was luck enough that the first thing I really want to move has none of those. So I have some time.

I’m just wondering if there’s any cause for concern right now.

#2

github can add meta file, just use github desktop.

my wiki is on github too.

#3

That should work fine; I do it all the time. As you note, this technique doesn’t work for binary tiddlers.

1 Like
#4

This is Enterprise GitHub and my company has blocked the upload of a number of file extensions – a large number of types, including obvious things like .exe and many forms of compressed folders (.zip, .tar, .ear), office documents, complied forms, and many others, 199 extensions in all.

On public GitHub I store many Node TiddliWikis, and it’s not a problem there.

#5

Thank you.

Yeah, and that’s going to get me to fight this. The trouble is that I’m still using TW in an ask-forgiveness-not-permission manner, so I might have to find an oblique way of arguing this point, or find some stupid hack to deal with this – renaming pre-commit and post-pull or something.

It seems extremely unlikely, but the extension name .meta is not configurable, is it?

#6

Maybe you can also used tiddlywiki.files - https://tiddlywiki.com/#tiddlywiki.files%20Files. I have only used these in my plugin dirs.

Example

{
	"tiddlers": [
		{

			"file": "styles.json",
			"fields": {
				"type": "application/json",
				"title": "$:/plugins/bj/visualeditor/styles.json",
				"module-type": "library"
			}
		},
		{
			"file": "config.json",
			"fields": {
				"type": "application/json",
				"title": "$:/plugins/bj/visualeditor/config.json",
				"module-type": "library"
			}
		},
		{
			"file": "verbatim.json",
			"fields": {
				"type": "application/json",
				"title": "$:/plugins/bj/visualeditor/verbatim.json",
				"module-type": "library"
			}
		}
	]
}
#7

Ah, that might well do it for me! Thank you. I’m going to have to read that more carefully soon.

It will still feel like a hack, but perhaps a longer-lasting, cleaner hack! :wink:

#8

https://tiddlywiki.com/static/Customising%20Tiddler%20File%20Naming.html

File System Extensions
Normally, the file system extension of a tiddler on disk is determined by the presence of field values containing newlines or field values that start or end with whitespace (other than the text field), in which case the single file “.json” tiddler file format is used.
If the tiddler does not have such field values, then the type field is referenced to find a matching file-type, with .tid used for tiddlers without a type value. The boot engine defines a set of these tiddler-type to file-type relationships in the $:/boot/boot.js tiddler. Search for // Add file extension information to find the section of code that defines these relationships.

The file extension of individual tidders can be customised by creating a tiddler $:/config/FileSystemExtensions containing one or more filter expressions, each on a line of its own. Every time a tiddler is saved to disk it is tested against these filters, and the first output of the first filter to produce any output is taken as the file extension to be used for the tiddler file. Extensions should always start with a leading dot (see example). If no filter matches, the default extension is used. If the extension has changed a new file is created and the old file is deleted.

Note

A result of “.tid” will force the tiddler to be written to disk as a single-file text tiddler. A result of “.json” will force the tiddler to be written to disk as a single file tiddler in json-format (a single tiddler fields object in an array), NOT as a tiddler of type “application/json”. All other recognised file-types will be saved using their defined extension along with an accompanying *.meta file of the same name which describes all fields but the “text” field.

You want: (title) $:/config/FileSystemExtensions

[then[.json]]
#9

Thank you.

I’ll try to play around with this when I return to work after a long weekend and can check that environment. But the thing I would want to do is to use some other extension than .meta, and perhaps I’m not reading this correctly, but this will still use .meta for the additional fields, wouldn’t it?

#10

Ah, but we are not setting the tiddler-type to application/json, we are Overriding the Extension to *.json. This is a special case in the filesystem plugin that forces the tiddler to be written as a single Title.json file with all fields as one json object. Without any actual tests in that filter line, ALL tiddlers will receive this override. :slight_smile:

#11

Ahh, I get it now. Thank you @joshuafontany !

#12

Two years later, I’m back on this work, which had been abandoned about the time of my last post. I just ran into this issue again.

I immediately remembered asking about it, found this thread, and it solved my problem precisely.

Thank you very much for your help, @joshuafontany, even if it took me a long while to implement it.

1 Like