A small tool to import links to files instead of files

,
#1

Hello, everyone!

I would like to announce a small tool, which keeps your TiddlyWiki small by creating tiddlers with links to files or HTML elements wrapping the files, instead of importing the files themselves. The tool is provided as a web page here: Import links to files into TiddlyWiki.

The tool uses img tag to embed images; audio and video tags are used for audio and video files, both with controls.

The import process consists of two steps:

  1. Copy files to add into the directory of the wiki (or vice versa)
  2. Drag-and-drop the files to import onto the page
  3. Drag-and-drop the resulting list from the page to your TiddlyWiki

The GitHub repository is here: GitHub - wincentbalin/tiddlywiki-file-link-import: Import links to files into TiddlyWiki

Any suggestions, bug reports, or praises are welcome!

Kind regards,

Wincent Balin

6 Likes
#2

It’s great! Took me too long to realise that this is for single file wikis (where this functionality is needed most) - doesn’t work with node.js

For the challenged like me - a) copy the media file to the same folder as the target TW b) drag and drop from the folder to the magic TW c) drag the “list of files” to the target TW

Nick

#3

This is a smart solution by @Mark_S

It simply gets a text file and create all the images/pdfs/… as canonical uri

https://kookma.github.io/TW-Scripts/#Create%20External%20Images%20from%20A%20Directory

EDITED: The link was corrected.

#4

@wincent

Welcome to tiddlytalk

Could you please explain this a little more, what is its scope?

  • Is it only urls to files that Import?
  • Could we install something like this also in the target wiki?

As far as I can see on dropping a file on your utility wiki, rather than import the file, it generates a tiddler with the title set as the filename containing a simple html link eg <img src="colorpicker.jpg">, which you then drop on the target wiki.

  • This method only references the files that are found in the same folder in which the wiki is found.

Does this sound right?

Thanks for your contribution.

#5

Hello @NickB!

Indeed, this is for single-file wikis, as the node.js-based ones store files within filesystems anyway.

The basic idea was to use TiddlyWiki as a digital notepad with tags and text search for a set of media files, this set being in the same directory as the single-file wiki itself. Also usable as a presentation file, or as a juke box for linked audio files, the possibilities are countless.

And it does not look that you are challenged at all, as you describe the import process in the second paragraph just right. :slightly_smiling_face:

Kind regards,

Wincent

1 Like
#6

Hello @Mohammad!

I found this kind of import (using _canonical_uri) too, but my use case was to use a wiki as a notebook for media files within the same directory, to avoid any issues with relative paths.

I thought about linking to files, rather than embedding media files into a HTML wiki, after dropping 1 GB of media files into such a wiki file. I could save it, as well as reload it, but I thought that an existence of a HTML file with a size of > 1 GB should be reconsidered.

Kind regards,

Wincent

#7

Hello @TW_Tones, you are welcome!

About the scope of the tool: you guessed right, it creates tiddlers, which contain HTML tags that either embed media files or contain links to (non-media) files; the tiddlers are named a the file they link to and the files must be in the same directory as the wiki to avoid any issues with relative paths.

It is interesting that you are not the first one to ask about installing that tool within a TiddlyWiki. In my opinion this would interfere with the default drag-and-drop process of TiddlyWiki, but I do not mind at all being proven wrong. @jeremyruston, what do you think about this idea?

Kind regards,

Wincent

#8

Could you get the absolute path of the HTML file (there is system tiddler with this), and compare it against the absolute path of the target to determine the relative path of the target?

#9

Hello @clsturgeon!

As per HTML Standard, the files transferred using drag-and-drop contain only the file name without any path information; hence any path comparison is impossible. This inconvinience is whence the idea of storing the wiki in the same directory as the files imported came.

Kind regards,

Wincent

#10

@NickB, I added the first step from your list of steps to mine. I suppose this clarify the scope of the tool a little more. Thanks for the idea!

Kind regards,

Wincent

1 Like
#11
  • This is true, but we can also copy a path/folder into our wiki then use it to prefix the subsequent “filenames we import”.
  • Thus we can “add files from any accessible path” we just need to do it a folder at a time, with a path prefix captured for each.
  • Smart design would allow this prefix to be modified in future to indicate files moving to another path. Perhaps using relink to do this?.

I am actually doing a lot in this space, one key trick is to store the full path and filename in tiddlywiki, then just before opening an “import or save dialogue” copy the full path and file name to the clipboard, then pasting this into the open or save dialogue eg Ctrl-V in windows.

  • I primarily do this with JSON packages to save an updated version or load the latest version.
  • Capture the full path once and its available indefinitely.

I can imagine a custom drop zone as @wincent has created, one that bypasses the import process, but in the target wiki and also with the ability to set the path to be applied to subsequent file drops.

  • in TiddlyWiki you use the Browse widget, then find the folder, r-click and copy path, cancel return to the wiki and paste the path. #1
  • Then on the next browse or download operation the button also uses tm-copy-to-clipboard to automatically copy the saved path to the clipboard and paste it if you need to, in your open or save dialogue to navigate to that path.

#1 There may be other effective ways to collect full paths for locations containing files within the browser, because you can see folder structures in browser tabs using the File:// protocol

  • A “browser add on” to support the copy of a full path and/or filename from this screen would be a useful way to capture and store full paths in ones wiki.
  • Similar method’s could be used for URL on hosted wikis. eg mydomain.com/images/

There are additional caveats and considerations using this approach to keep in mind, but it does add powerful interactions with the local file system,

#12

I found somewhat of an answer myself. For at least a single path file or folder.

<input type="file" id="fileInput">

Presents the browse button but can do nothing with the selection however while in the dialogue box you can copy to the clipboard path and other information to a file or folder, then on returning to tiddlywiki paste the result where you want.

Using a clipboard manager you can copy and paste multiple. eg win+V

Organizing computer data files and matching to TiddlyWiki
#14

For security reasons, browsers do not expose the full path to the selected file.

However, TiddlyDesktop does offer exactly this feature via the “External Attachments” plugin that is in the official plugin library.

1 Like
#15

This works via using the windows dialogue copy as path. And paste on return to tiddlywiki.

Note: Unlike the external attachments plugin which;

Only works when using TiddlyWiki with platforms such as TiddlyDesktop that support the path attribute for imported/dragged files.

This method works via the clipboard, for any path or filename, using a dedicated function like r-click “copy as path” or r-click copy, and then you need to paste into the place you want in TiddlyWiki.

  • Rather than ctrl-V I have a function key that pasts with one press.

FYI: @jeremyruston @tw-FRed

#16

TiddlyDesktop has External Attachments , and TidGi Desktop has TidGi External Attachments plugin in CPL too.

With a desktop app, this is getting a lot easier.