Improve Plugin Handling for data tiddlers.

[AnthonyMuscio]

Plugins are useful to package functional additions to tiddlywiki. Often they contain macros and Javascript.

Disabling a Plugin will disable such Javascript and functionality but currently it will not hide its shadow tiddlers.

The consequence of this is;

• If more than one plugin contains the same named tiddler it is not transparent which will win.
• If a plugin contains packaged settings even is disabled it can change the behaviour of the wiki
• There is no way to toggle the existence of such shadow tiddlers into or out of visibility.

Proposal

• Either the Enable/Disable button should hide the shadow tiddlers in a plugin
• Or an additional "Hide Shadows" button be provided to do so, this could be set to appear only when a plugin is already disabled.

See also #5336

[Jermolene]

Disabling a Plugin will disable such Javascript and functionality but currently it will not hide its shadow tiddlers.

I don't think that is correct. I tried disabling a plugin using the button in control panel, reloaded the wiki and found that the shadow tiddlers were not present.

[AnthonyMuscio]

Jeremy,

You are not wrong, about the need to reload., but the OT request still stands, Improve Plugin Handling for data tiddlers.

I was in part fooled by the complexity of what I was doing. I was using plugins as data after importing using the JSON mangle plugin.

The reload is the critical step. As you know it is now possible to install a plugin with without the need to reload if it does not have javascript components or system modules. The reverse is however not true, if you toggle the state of a plugin between enable or disable the shadow tiddlers do not not appear or disappear until you reload.

It would be great if the original request, could be satisfied without the need to reload.

An example use is a plugin of various tiddlers that toggle UI config settings, a tiddlywiki could contain a set of alternative configurations where selecting enable or disable on different plugins (data or config tiddlers not javascript), will make a different set of tiddler values "active", needing to reload makes this less practical.

I do not know how difficult it is technically, but it would allow additional methods to be used when plugin tiddlers are used for data sets. One can thus toggle which dataset (viewed as shadow tiddlers) is present and active without the need to reload.

Regards
Tony

[Jermolene]

Hi @pmario

I'm modifying the $:/core/macros/tabs macro. .. So we probably need some info in the plugin, that tells the core: "Even if the plugin doesn't contain js-code, it needs a restart". ... OR something similar

That sounds like a bug. Are you just overwriting the core tiddler containing that macro, or are you defining overrides for some of its macros?

[pmario]

I think the new import mechanism for "wikitext only" plugins doesn't do a full page-redraw. Importing global macros is part of the $:/core/ui/PageTemplate. .. I think the refresh doesn't go "deep" enough. ... BUT I didn't investigate further yet.

[pmario]

ATM I'm replacing the tiddler, I couldn't find easy ways to insert/implement the needed DOM elements. The plugin is: https://wikilabs.github.io/editions/link-to-tabs/

[pmario]

BUT may be that's OT?!

[AnthonyMuscio]

@Jermolene

I intentionally did not run into the details to present a compelling use case, lest a "verbose post" stop people considering my idea, I will post on this shortly.

Absent a compelling use case, I can't see the motivation for making things more complicated.

But some points;

• I can drop a data tiddler (Non JS Plugin tiddler) and it is immediately available (as is its shadows)
  Subsequent retention in the wiki and to toggles the shadow tiddlers requires disable/save wiki/reload, and to restore enable/save wiki/reload
• The first and most compelling reason would be both consistency simplification with the implied functionality that the no reboot install facility give the user
• Increased simplicity
• allows this activity to take place on read-only hosted wikis where a save/reload is not possible
• I will document the use case in separate reply.

On Introducing complexity

• I am confident there is a simple method, so the value of such a change reduces complexity.
• As you highlight, deleting the plugin-type does achieve the desired result, the disadvantage being it is no longer listed as a plugin.
• Even changing the plugin-type to an arbitrary value such as "data" will not stop the delivery of shadow tiddlers.

Regards
Tony

[AnthonyMuscio]

Compelling uses case to support the OT.

Background
Tools such as the JSON mangler and other more manual methods allow large or small amounts of data to be imported as a plugin with each "record" presented as a shadow tiddler. Source's may include csv or database files or publicly available information such as post codes, airport codes, archaeological epochs and much more.

• Personally I have a "data" with 200+ products from my online store in a single plugin tiddler.

The value of "data" plugins.

• Once available such "data" plugins allow the wiki to interrogate the content as shadow tiddlers, and edits can be detected if they become tiddlers. It is possible to distribute such "data" plugins as reference material, in libraries and make use of the update mechaisium.
• Such tiddlers could also contain User interface layouts, bundles of configuration tiddler settings and more.
• If we can simply toggle one plugins shadow tiddlers off, and another tiddlers on we can "bulk" reconfigure the whole wiki in a click.
• If such a data plugin is updated (with the same but updated tiddlers) the same wikitext and macros can apply to the same suit of tiddlers.
• If we can toggle off the shadow tiddlers (without a reload) we can retain such a "data plugin tiddler" as a JSON and even compare the contents with the updated and current version with ease in interactive wikis or on top of read only hosting (That can't save and reload).
• It would be helpful to know if more than one plugin is active that contain the same shadow tiddlers, which is the one "that wins".

If needed I can present more on the use of "data" focused plugins but would also ask that this be considered a hackability extension as well.

I will post separately on a possible method to address this with out impacting existing behaviour. Data tiddler handling suggestion.

Tony

[AnthonyMuscio]

Data tiddler handling suggestion
minor addition at bottom

As a respected mentor once said, if you come to me with a problem, please also propose a solution.

The simplest version that would be adequate and allow me to create a plugin to support "data tiddlers" would;

• introduce a sate tiddler that can toggle hide-shadows = yes/no on any plugin, and hide/show shadows accordingly using the same mechaisium that stops shadows when one removes the plugin-type field. Without the need to save and reload.

This is my idea for "data" plugins.

• Register a new plugin-type of data
• Present a new tab in $:/core/ui/ControlPanel/Plugins listing only "data" plugins
• Hide data plugins from the "Plugins" tab in $:/core/ui/ControlPanel/Plugins
• Enable a button on data plugins that "hides" the shadow tiddlers, while retaining the plugin-type data
• Provide a programmatic way for designers to toggle the visibility of the shadow tiddlers on data tiddlers.
• Such a toggle should avoid touching/editing the plugin tiddlers, and store this value in a tiddler similar to the other visibility state tiddlers. This will avoid the tiddler being modified or time stamped.
• If possible sort data plugins so the user can determine which will win if there are duplicate shadow tiddlers across plugins, or competing with a core shadow, Not unlike the stylesheets in $:/core/ui/ControlPanel/Stylesheets
• increase visibility of over written shadow tiddlers

Subsequently we can Provide tools to

• save edited tiddlers back into the plugin JSON (update)
• access the value in a tiddler/field in the shadow

Related issue

• [IDEA] Lookup Operator extended to permit fieldnames [IDEA] Lookup Operator extended to permit fieldnames #5307 (additional options for data tiddlers)

Related but not dependant discussions

• Import Mechanism - enhancements Import Mechanism - enhancements #5336 (so data plugins can have new prefixes added/removed to every shadow at import)
• Extending the IS and All Operator for custom definitions Extending the IS and All Operator for custom definitions #5314 (allowing custom data plugin IS and ALL operators)

An IS or All Operator such as IS[product] or ALL[product] where the filter(s) access the "product" tiddlers of a named data tiddler.

Regards
Tony

[pmario]

Did you try a theme-plugin. themes can be easily switched

[AnthonyMuscio]

I did not, but I can look into it thanks. Perhaps a plugin-type that works like themes.

[AnthonyMuscio]

Looking at themes $:/snippets/themeswitcher or $:/snippets/minithemeswitcher seems to switch only one value, the current $:/theme content. I will explore this further for inspiration on "data plugins" but it does not yet seem a hackable mechanism.

I do see how unselected themes remain in the theme plugin list, yet their content is not present. I will need to further research the themes mechanism.