Converting tiddlers to shadow tiddlers by moving a package to a plugin

#1

Folks,

I have hundreds (no exaggeration) of packages of tiddlers that provide solutions, tweeks and tools for us in tiddlywiki. Effectively a set of regular tiddlers I export as a single json file, and import, drag and drop or make into a bookmarklet for istaltion when needed. It usualy includes a package tiddler with details about the package.

  • I am hoping to publish these to the community
  • Although I do provide them as needed in talk.tiddlywiki I believe people expect such solutions to be plugins.

All such packages have being developed using standard tiddlers and as a result may not operate when converted to shadows, or will they?

Special mention

I need to thank @Mohammad for his Gatha plugin as it allows me to avoid loosing functionality as I move from package to plugin and back by restoring some of the advantages of accessing plugins as regular tiddlers.

Question

I would like to know from expierence tiddlywiki designers and developers where they think I need to look to modify tiddlywiki script to ensure the package continues to operate as a plugin?

1 Like
Gatha 2.0.0: Create Plugins and Packages in a Second
#2

While I may not qualify for the question, I’d still say “just make a plugin and test it” - ? Or how is that a problem to do? Besides, how useful would a reply be when it is totally based on hypotheticals and assumptions about your creation?

That said, one potential problem I can see is IF your solutions contain overwritten core tiddlers; they are then no longer non-shadows so there can be conflicts with the originals.

#3

I am doing that but that is only a specific case, and does not capture systematic issues. I was hoping some know what this issue is.

  • As I convert a lot of these I will learn but I was hoping for some advanced insight.

An example maybe when using a list widget, if the filter needs to list system or shadow tiddlers the filters may need to be modified. Although most content tiddlers tend not to be shadows buit an example of ones that are is data plugins https://test-data.tiddlyhost.com/

#4

What is “this issue”? What is only a “specific case”? How is anyone supposed to understand what you’re referring to here? (A reflection: It is both kind and generous of you to want to share your hundreds of solutions, I just hope they are clearer than some of your posts or I fear people may not appreciate them as much as they possibly deserve.)

#5

I suppose it depends on how good you are at context.

You said

That would only address a specific use case, a particular plugin. Only the issues in that plugin if any will come to my attention.

As I convert a lot of packaqes to plugins, I will test them and find out the issues, I just hoped others did this to know what the issues are, given the title of the thread “Converting tiddlers to shadow tiddlers by moving a package to a plugin”.

  • I will try and be clearer in future.
#6

Hello TW_Tones,

I am not facing specific issues while converting standard tiddlers to plugins.
This is my usual workflow (20+ plugins created that way using Tinka to create the plugins).

Therefore I am not sure to understand where your issues are.

BR,

Eskha

#7

The most important thing for a plugin is the

Plugin Namespace

  • $:/plugins/<author>/<pluginnmame>/<title> eg:
  • $:/plugins/<author>/<pluginnmame>/readme
  • $:/plugins/<author>/<pluginnmame>/license
  • $:/plugins/<author>/<pluginnmame>/config … optional if needed
  • and so on …

Config tiddlers

  • $:/config/<plugin-name>/<config-title> are an exception, because they can be part of the plugin, but start with $:/config/
  • They still should have a relation to the plugin, so they are easily identifiable.
  • The best way to work with config tiddlers is, to not package them at all, but work with sensible default values, if the config tiddler is missing.

That’s the way we work with most configuration tiddlers in the core. They only exist, if users need to change them. Only if there is no other way they are shipped with the plugin.

Installing a Plugin

  • Plugins should never automatically overwrite config tiddlers from other plugins.
  • Plugins can rely on core config tiddlers, but only the user should overwrite them.
    • Core config tiddlers, can be listed in the plugin settings tab if needed.

Overwriting core tiddlers

Should be avoided if possible. It creates maintenance burden for users and plugin authors.

  • Plugins should clearly identify core tiddlers, that are overwritten by the plugin in the readme
  • If possible only portions of existing core macros should be overwritten, if possible.
  • Many core macros allow to overwrite default templates. If that’s possible plugins should use that mechanism

Identifying core tiddlers that are overwritten by the plugin can be done with a filter.
eg: my AdvancedSearchPlus plugin uses the following filter and info text in the readme.

''Important'': This plugin modifies several core templates

<ul>
<$list filter="[[$:/plugins/wikilabs/advanced-search-plus]plugintiddlers[]prefix[$:/core/]] $:/AdvancedSearch">
  <li><$link to=<<currentTiddler>>><<currentTiddler>></$link></li>
</$list>
</ul>

This makes it easier for users to identify update problems.

Plugin Settings

IMO plugin settings (only if needed) should also be part of the ControlPanel → Settings → Author → Plugin Name tab — This is no “hard rule”, but I think it makes sense.

See ControlPanel Settings Screenshot

image
image1921Ă—641 62.5 KB

Since I do have so many plugins and if there are several of them installed, I moved the settings / config options into it’s own tab. I think that’s better than “polluting” the default settings tab.

I think that’s the basic rules I follow with my plugins.

3 Likes
#8

Thanks @pmario,

if I add to that any filters that now need to also refer to shadow tiddlers, within the plugin, may need to be changed. This would likely be rare, however would typicaly be a filter than includes the prefix or tags to tiddlers within the plugin only. in which case the filter may need to start with [all[shadows+tiddlers]..

This should be quite comprehencive.

#9

Unfortunatly when trying to build a filter-pills plugin from my existing filter-pill.json package once I move it into the draft state into Gatha it has stopped working. This is in part why I started this thread, however they have not even being converted to shadows in a plugin.

  • I am starting to troubleshoot it.