Import package of tiddlers with instructions to delete a tiddler?

#1

I like to make use of packages of tiddler that I export in JSON files, I also sometimes pack this into a bookmarklet to install with a single click.

For some of my larger packages I occasionally release a new version with updated tiddlers. I simply reimport the package and all tiddlers are replaced with updated ones, new tiddlers are added.

There is however no mechanism to include in such packages a way to indicate an existing package tiddler is to be deleted.

  • As a result I need to delete all the tiddlers before reimporting the package again, just in case.

Has anyone tried to address this already?

Perhaps we could define a mechanism to indicate a tiddler in the import is instead to be deleted if it already exists?

  • This may be as simple as a “de facto” standard fieldname eg delete-tiddler-on-import=“reason the package wants to do it” in the tiddler to be imported.
  • Perhaps later make this a “de jure” standard.

We could update the Import mechanism to list these and give the user the option to review and select the tiddlers to be deleted so there are no silent deletes?

  • This is even more important when we have previously overridden a system tiddler and not longer need to.

If we are updating the Import mechanism we could also differently highlight imports that override system tiddlers, and especially system tiddlers that have already being overridden.

  • Which is what occurs when there are clashing changes.

The idea is to detect this and leave it to the user to resolve, whilst providing some helpful tools.

1 Like
#2

Yes. Me.

But I am NOT happy with the solution.

In my sidebar I have a tab, PURGE. This contains all purge information “current” at the time of the import (bundles, in my case).

Don’t get me wrong, it works fine. But after ~10 years, my “purgelist” tiddler is now a very long list (245 entries). I can’t trim it down just in case I open an ancient tiddlywiki, apply the latest bundle (currently 926 tiddlers) and the one tiddler that’s causing me a problem has been removed from the purgelist and I won’t have a clue what that tiddler might be.

#3

In my case all of my project tiddlers are tagged. So, I wrote an update tiddler where the user purges all project tiddlers and imports the latest project update. This update tiddler does other things as well, such as confirm that prerequisites have been met. Example: It confirms necessary plugins exists.

If I want to get real clever I add data checks in this tiddler.

#4

If you bundle your tiddlers together into a plugin, then it is just one tiddler to replace every time. Any additions/deletions/modifications inside will automatically take place. Have you considered that approach?

#5

good point, however, I have considered that approach, but that is still not exhaustive because of any of the plugin tiddlers were overwritten, usually config tiddlers, many that you are happy to retain for sure, but they will remain after replacing the plugin. But your are right, that a plugin, handles many a use case.

  • We may also occasionally have issues if our plugin contains an override of a core tiddler. Plugins only do so via a shadow tiddler, we cant see the difference between a core shadow and plugin shadow.
  • Have thought of making an uninstall process, but again this is another step.

Using plugins
The transition from a filter to a simple plugin is not too hard but building a proper plugin, with “readme”, to see the details where you expect them, is a bit more involved and makes the workflow more complicated, especially to only make a few changes.

Using JSON packages
I actually have a sophisticated set of tools to build, export, import or simply drag and drop JSON packages from a simple button, with a filter behind it. The only gap is the delete process.

Hybrid solution?
I would like to solve these gaps both in plugins and JSON packages, and I can do it myself, but it has more value if the core contains the mechanism, so we don’t need to install something, just so we can install something and retain the integrity.

  • It is for this I am soliciting ideas.

I am now working with Gatha to release my “reimagine tags solution”, as a plugin, and will be more familiar with the plugin mechanism, I may find a solution there.

#6

FYI, if you have tiddlers in json format, there is an easy way to create a plugin from it:

  1. Drag the tiddler json onto a tiddlywiki
  2. Edit the $:/Import tiddler. Change the plugin-type field from import to plugin
  3. Rename and save the tiddler
  4. The tiddler is now a plugin

Just a quick and dirty way which works because the import process uses the same format as a plugin (except with a different plugin-type). Something like Gatha is better for anything other than experiments.

Custom plugin type
#7

2 posts were split to a new topic: Custom plugin type

#8

Thanks @btheado but that is what I mean when I said;

Again your are correct, but I am still keen to resolve the OT to include in a JSON package an indication of some tiddler s to remove.

  • Using this method demands the package of tiddlers are already deployed by plugin.

I have played with these alternate plugin types quite a bit, so happy to work through this with you, but perhaps please, be carful not to hijack this thread.

Where next?

Keep the ideas coming and I think I am slowly seeing a way forward, Inspired indirectly by your comments and replies.

I wonder if in the case of a JSON package, and possibly even a plugin, in which we wish to “specify tiddlers to delete” (if they already exist) ;

  • We add to a package a small tiddler, even a plugin, lets say we call it “install steps”, then on import the user opens it and presents additional installation notes / buttons or instructions including delete tiddler options?
    • Ideally it is indicated somehow and the Import process brings it to the attention of the importer.
  • One advantage is it all will be quite “transparent” and optional, to the user.
#10

A post was merged into an existing topic: Custom plugin type

#11

You could experiment with this tiddler:

https://tiddlywiki.com/#%24%3A%2Fcore%2Fui%2FViewTemplate%2Fbody%2Fimport

Change the button to perform more actions beyond just performing the import:

<$button message="tm-perform-import" param=<<currentTiddler>>><<lingo Listing/Import/Caption>></$button>
1 Like
#12

That would certainly improve my purgelist method. Thank you!

@TW_Tones Going back to your question, can you see that answers your OP? ← perform a delete action on any found tiddlers that should be purged…

#13

Yes, this is where I was expecting such modifications may be made.

  • The fact is that on importing a plugin the tiddler, we only import a “single physical tiddler”, and this tiddler, the tiddler containing the subtiddlers within has its it’s own fields. We could provide a list of tiddlers we want the import to propose we delete, in one of these fields. Lets call it the “request-delete” field.
  • JSON Packages however are json files, and do not have this field meta data. Instead we have to include a tiddler that contains this metadata that the Import process can read the “request-delete” field in.
  • It is a workaround. As I understand it, it asks you to do something before you do something else, or in the first place collect the titles you may later wish to purge. I would like to package it in the objects we import.

So thinking about this further;
The fact is we could make an alternate package based on the .tid format (although I would suggest a different extension), that has the subtiddlers encoded within it, but also has the field metadata that would allow us to provide a request-delete field.

  • This is very similar to a plugin tiddler, so perhaps I just hack the plugin tiddlers.

What is the difference between a JSON package and a Plugin?

  • A Plugin is a tiddler, containing tiddlers we make into shadow tiddlers.
  • A JSON file is a file of tiddlers we turn into standard tiddlers during import.

Where to go from here, speculation?

Inspired by this discussion perhaps we can just add some custom fields to a plugin tiddler. Leave the plugin and Import mechanism alone. Once a plugin is installed it will work as advertised, but is also containing the additional fields. Like aforementioned list of “request-delete” titles, and any other special fields.

  • Then if the receiving wiki has the tools to interrogate these fields, we can have a request delete process and other special features, like an install script, that uses a shadow tiddler etc…
    • So we gain a new mechanism that can be used but only if you install the support tools, or review the fields manuallyy.

I will give it more thought, but any ideas continue to be welcome.

I will try and contribute to Custom plugin type where I have already researched a lot.

[Post script]

I have currently banned myself from any substantial TiddlyWiki work between 9am and 5pm weekdays local time to prove it is not an obsession and get other “more important things” done.

[Post Script 2]

I realise now we can already add an interactive payload which can include delete requests, shadow to tiddler generation and more by simply adding a tiddler to the plugin package just like readme and name the tab. A simple import addon, that does not modify any core tiddlers can advise the user at import.

  • I will look at making some tools to support this.
  • I will have to address the fact that I have a large number of JSON packages I may need to convert to plugins, or an alternate export plugin, that does this for me.
1 Like
#14

That’s how my purgelist works in my mega-bundle. Perhaps @pmario might see his way to formalizing the idea of a request-delete field or a purgelist. It’s not exactly necessary, my system works fine, _but only if I remember to look in the purge tab…

image

#15

I personally think automatically deleting tiddlers is a very “destructive” functionality. So we need to make sure, that this action is executed intentionally to avoid data loss.

My bundler plugin has a possibility to remove single tiddlers one by one as described at: new-in-v1.0.0.

See the screenshot below.

  • The delete button on the left does not ask for user consent it removes the tiddler from the wiki.
  • There is an “Open in AdvancedSearch” button, which opens the list in $:/AdvancedSearch
  • $:/AdvancedSearch has a “batch delete” function, which can remove a lot of tiddlers in one go.

new-story-buttons-annotated
new-story-buttons-annotated1888×568 57.3 KB

I know that’s not exactly, what is discussed in the OP but it would work for me.

A bundle could contain a “purge tiddler bundle”, which can be used in the way I did describe above.

That would be good enough for me.

just my thoughts
-mario

#16

There is a difference between automation and automatic. Perhaps it could be said, Automation makes it easy and automatic does it without intervention.

It looks like your bundler tools have evolved. I have being using my own mechanisiums for a while I may need to revisit.

This is all closely related so do keep sharing.

Interesting. I am inclined not to use purgelist as to me it implies tiddlers they are ones that have built up and just needs to be removed, where I think sometimes deleting a tiddler may be of some consequence.

  • I love learning about these diverse approaches.

I would like to continue exploring the idea of piggybacking on the plugin mechanisium and/or adding features to the import mechanisium.

  • in part because I have a substantial investment already in json tiddlers
  • and also to intergrate it closely to the core.
#17

:+1: Exactly. That’s what I’m doing with a purgelist. When the megabundle is imported, a tab presents any tiddlers matching the titles listed in the purgelist tiddler – with a purge button alongside each of them.