Initial feedback on File Uploads beta

[boris]

Hi @saq, I installed the file uploads plugin in my twgroceries instance. Public link is https://boris.files.fission.name/p/twgroceries/

Install worked no problem.

A few notes. I can file issues if you want, but I think helpful to write about it long form for now.

File path is relative to my files root, not TW root

For the Fission uploader, the file path I assumed to be relative to where my TW HTML file is. So, when I changed the folder name to assets, I thought it would be at https://boris.files.fission.name/p/twgroceries/assets, but instead it was at https://boris.files.fission.name/p/assets/.

This is not a problem, and reading the plugin docs I see that it says Upload folder path relative to root of public folder. If possible, adding an example of the path like username.files.fission.name/p/files might be needed here.

To get what I wanted, I guess I would put in twgroceries/assets in the setup.

File rename based on tiddler rename was unexpected

I’m trying to think back to what I did.

I drag and dropped two images straight from my photo library, so IMG_5614.JPG.

Then, I changed the name of the tiddler which contains the canonical URI to be Fruit Plate at Twisted Fork and it rewrote the image to be named that. This loads no problem and URL escapes the path so it loads https://boris.files.fission.name/p/assets/Fruit%20Plate%20at%20Twisted%20Fork.

But, my expectation was that the canonical URI wouldn’t change. My suggestion is that once a file is uploaded, it shouldn’t change file names.

Keeping an “upload log” may be helpful in the plugin settings, so I can quickly access all the canonical URIs? Don’t know.

Error message when not in edit mode

You probably saw this message as well when visiting the public link above. This is related to other discussions about an interactive mode vs. “view only” mode. I’ve tried various things with my twgroceries install around this as well.

Turning off the uploads via the icon which in my theme is top right makes the error go away.

I don’t think anything to be done here, just noting it.

[saqimtiaz]

Very useful feedback, thank you @boris

@boris

For the Fission uploader, the file path I assumed to be relative to where my TW HTML file is

I spent some time thinking this one over in terms of what would be most intuitive from a user point of view, relative to wiki file location or root of public folder. Part of my concern was that when you are editing in TiddlyWiki on Fission, you don’t actually see the proper path of your wiki in the URL.

I would be happy to revisit this once we get some more user feedback. Relative to wiki file or public folder could even be a setting for the uploader. For the time being I’ll make a note to add an example path as you suggest.

@boris

Error message when not in edit mode

I am glad you mentioned this as it has been on my mind. Part of the catch is that we don’t really have a clean separation of view vs edit modes in TiddlyWiki. One solution would be publishing a public copy of the wiki that excludes certain tiddlers such as the Uploads plugin or include configuration tiddlers that set the wiki to read only.

I considered having the File Uploads plugin respect the readOnly setting for TiddlyWiki. When used with the nodejs server configuration with authentication, it is possible to have a readOnly mode as indicated by the $:/status/IsReadOnly tiddler. The issue is of course that there is no mechanism to determine and set this for single file wikis. One approach could be a startup script for TWoF that checks the URL or presence of webnative to determine whether to set readOnly or not, however this also feels brittle.

Elegantly handling read-only wikis that have the File Uploads plugin installed is an area that I would welcome input on.

I will investigate the file rename issue and report back.

[saqimtiaz]

@boris

File rename based on tiddler rename was unexpected

…
But, my expectation was that the canonical URI wouldn’t change. My suggestion is that once a file is uploaded, it shouldn’t change file names.

I have not been able to reproduce this behaviour for files that have completed uploading, i.e. the tiddler in question has been converted to a _canonical_uri tiddler.

I can however envision two scenarios in which a similar behaviour could occur:

a) The tiddler is imported and renamed while file uploads are disabled, and then file uploads are enabled.

When TiddlyWiki imports a binary file, the tiddler created is the file and the filename persists only in the tiddler title as long as it is not renamed. So if the tiddler is renamed before being uploaded, there is no means by which to recover the original title.

b) The tiddler is renamed while it is being uploaded.

TiddlyWiki treats renaming tiddlers as deleting the tiddler with the old title and creating a new tiddler with the new title. If a tiddler is renamed while it is being uploaded, when the upload completes a _canonical_uri tiddler is not created for the previous tiddler title since it no longer exists, and then the tiddler with the new title is uploaded generating an uploaded file with that new tiddler title.

One of my early ideas was to show a visible indicator when editing a tiddler that is queued to be uploaded. We could revisit this idea. I am not sure how well it would mesh with future plans for the core - or even the current plugin architecture - but the plugin gives us the opportunity to explore such ideas.

If you manage to recreate the problem outside of these two scenarios please do report back.

[boris]

I most likely did (b) as far as I can tell.

I wouldn’t worry about it, it’s an edge case to do with the uploading process. Documenting it is good enough for now.

There might be a “sync” process that is related to bulk import, too. That is, if as part of importing/syncing a folder full of files, canonical uris are identified which MIGHT refer to the same file as is being imported.