When I drag a tiddler from another TiddlyWiki to my wiki and if the creator has used a username then the username is displayed in the tiddler subtitle (actually the modifier field is used, so not strictly the original creator.) That’s great - knowing who last modified the tiddler is important, as is knowing the original creator as shown in the fields. But many times I don’t remember where I got the tiddler.
Is there no reference to the origin of a dragged tiddler anywhere? If not I think the origin, if external, should be added to the tiddler’s fields in order to give proper credit.
At the moment, the TW5 core doesn’t support something like this.
… We did have some information about server.workspace in TiddlySpace, which was for TWclassic and a client-server based platform.
The nodejs version still has some elements of this naming schema in the server paths …
The problem with information like this is: … It breaks, when the server or the URL is gone, as it is the case with tiddlyspace. …
I know, that the Fission version would be able to create IPFS URLs that are unique and won’t break that easy. … But “normal” file TWs should also have info like this.
I do remember, there was some discussion about an origin field, which could store that info.
At the moment you’d need to add that field manually, with some information where you got it from and in my case I also need a “why” …
As I do with my own bundles of macro tiddlers I simply have a wiki-name field in a master tiddler or on all tiddlers in the bundle. I do this on tiddlers where the origin is important such as pointing to the “source of truth” or the master copy.
It could be possible to inject the wikiname in draggable tiddlers bu8t I don’t need to go that far.
With an search and indexing tool you can always search more than one wiki for a given tiddler.
I think the interesting question is if “referer” or origin is available as part of drag and drop.
Figuring this out as a script / custom solution first would be where to start.
This doesn’t actually help with “source”! The links are unique for the content (eg a plugin or a .tid) but not the location. In this case we want to know it came from bmannconsulting.com or whatever.
So — copying across the referer / origin URL would be the best starting point if that is possible. The original ask is if this is possible to get automatically from a drag and drop operation. Does anyone know?
Yes this in the IPFS solution would be cool if not important.
This in an example of something that may not have a simple technical solution by does have a social engineering solution. Allow users to save the full path “origin” to a tiddler for use when needed. As I mentioned the idea of a Wiki name should also be a de facto standard we can leverage.
Previously I have created download buttons,
first they copy the destination path to the clipboard (I provided earlier)
it then initiates a download,
when the save dialogue comes up I ctrl-v paste the file path and hit enter.
Then I hit enter and the file is saved to the desired local destination.
This workflow effectively over comes the limitations of browser apps being able to address anywhere on my local machine.
So — copying across the referer / origin URL would be the best starting point if that is possible. The original ask is if this is possible to get automatically from a drag and drop operation. Does anyone know?
I am not sure if I am answering your question, but I think the following can lead to a solution.
A drag and drop operation could be designed to add a field containing a saved origin to the tiddlers so dragged.
You can drop or paste the contents of the address bar, or permalink on tiddlywiki creating an untitled tiddler containing the full path. A Custom drop zone could be built as well and some if not all info can be extracted from the InfoMechanisium.
As I wrote. Half of the URLs are probably broken within 24 months [1]. …
May be if posted via GitHub pages it may be better, since they automatically add new public repositories to their Archive Program [2] in the repo settings.
Drag & Drop can probably be made to handle that. … BUT we would need to some additional input to the URL. There should be at least some “origin.description” that is added by the user.
I personally don’t change the $:/SiteTitle or $:/SiteSubtitle system tiddlers, that are shown by every empty.html in the GettingStarted page. … I probably should
This info would be usable and valuable for a dnd action as discussed in the OP.
The referer/origin is not made available by the browser as part of a drag and drop operation, so we cannot track the origin of links/images dragged from other web pages. But for dragging between TiddlyWiki documents we could certainly add a bit more metadata about the origin on the drag end; the hard part is deciding what to do with the metadata on the drop side. I’m not sure that there’s a universal answer to that, so it may call for some configuration options.
In my view there are some configuration options that may be helpful in this and other solutions; The need here is for them to be standard tiddlers so different designers and developers can refer to the same tiddler.
A tiddler containing a wiki-name eg $:/config/wiki-name (not unlike site title but URI compatible)
A tiddler containing a wiki-address eg $:/config/wiki-address (Such as domain/path or IP address, must be populated, and could be used to add a source field to tiddlers to be dragged.
A separate wiki-registration tiddler eg; $:/config/wiki-registration this would allow people to uniquify a reference to a specific wiki by combining this value with $:/config/wiki-name and perhaps in future we could obtain a registration number from a shared resource to get a form of Global wiki identifier.
Possibly a transfer-date field so tiddlers can retain there modified and created dates but record when the tiddlers were obtained from the source tiddler. In effect supporting change control and listing transferred tiddlers.
The tiddler names and fieldname are irrelevant, you choose. What is important is that they are chosen and documented so that they become a naming standard from an authorative source. They may not even need to be in the core just a standard.
If you went ahead to add a few such tiddlers, the community could possibly suggest a few more. I have at least two others in mind.
@Mark_S Thanks, not sure how I missed that idea myself, on default save, given how much I could use it.
I actually have a great workflow on my Windows computer that I can currently search, find, select an appropriate folder for downloads so I have not made use of this too much yet.
As per @Mark_S reply in this thread, standard tiddlers to hold a user entered “local file path and name” may also help simplify or at least document wikis who have a local device home.
Hi @TW_Tones as I say, I think it’s easy enough to come up with plausible metadata tiddlers that the source wiki can add as metadata to a drag operation. The problem is what to do with the metadata on the receiving end.
The idea here that we would automatically add fields to incoming tiddlers is not viable for me (although perhaps it could be available as an option) because it would mean that dragging a tiddler into a wiki would modify that tiddler. That makes it impossible to use a content hash to track that tiddler through the tiddlyverse. I also don’t like that it would create an inconsistency between tiddlers imported through different methods.
@pmario and I have discussed this at length offline recently.
I will try to be as brief as the subject allows.
On the The origin of the dragged tiddlers we were also looking at an idea about how the receiving wiki responds to dropped content, especially a json package of tiddlers.
We are looking at the idea of a kind of readme tiddler that opens (are rendered) automatically during the import workflow, before Import (this is manually possible at the moment) but we want a way so the publisher of a package of tiddlers can put some logic in that ends up in the face of the user, about to import the package. It may be as simple as automatically opening a preview of readme tiddlers text fields in the import table (no Javascript execution of course). An example may be to include an importedby field with the current user on each tiddler (timestamps off) or add an import date field etc…
It would be quite easy to allow a tiddler following some specification to be included when packaging a set of tiddlers that provides some metadata to the receiving wiki. This could include the Origin of Dragged Tiddlers. Or perhaps just an option that if activated adds a metadata tiddler on any drag, or say alt-drag.
The automatically opened readme tiddler, or meta tiddler idea actually allows logic to be imbedded and transferred with a package, such as dealing with contention, renaming, prefixing, displaying the source or other metadata or choosing if perhaps the imported tiddlers should edited in some way or time stamps changed. And can address this source metadata.
Someone may be able to drop a package of test data and select which items they want to actually import (with data aware selection), for their test case, rather than being forced to do this at the source (ie repackage).
To support the ability to include metadata in a package, the naming of some standard tiddler titles which will be a source of metadata, in the source wiki will help; as mentioned in my earlier reply,
That’s right. I mentioned, that the core in v5.2.0 will contain all the hooks necessary to implement a workflow like this and also a possible workflow as described in the OP.
BUT
It is plugin territory. As Jeremy mentioned:
IMO this question can’t be answered in a generic way. … It always depends on the actual usecase.
