Same shadow tiddler in different plugins: a question about priority rules

92 views
Skip to first unread message

mauloop

unread,
Mar 16, 2019, 1:09:25 PM3/16/19
to TiddlyWiki
I have a bunch of tiddlers that I use to import in every new wiki I set up. Some of them overrides shadows tiddlers from the core as well as from other plugins. I decided to organize all of these into a new plugin saved in the tiddliwiki/plugins/mau folder, to serve all of my existing and coming wikis via tiddlywiki.info.

I found few cases where tiddlers overriding other shadows tiddlers were ignored and the active tiddler was the one coming from the original plugin. I solved forcing the plugin-priority. The question is: having a shadow tiddler stored twice, with the same title, in two different plugins, with no plugin-priority defined, how can I guess which one will be used to build the wiki? I wonder which the general rule is, since I had some cases where I needed to force plugin-priority and others which work as I expected, despite plugin-priority was not defined.

As I said, my case is node.js with plugins served via tiddlywiki.info, but I expect that a single file does not make difference. Or not?

Thanks in advance,

)+(

Matthew Lauber

unread,
Mar 18, 2019, 1:26:43 PM3/18/19
to TiddlyWiki
My experience has been that the winning tiddler is based on alphabetical order, last plugin wins.  So $:/plugins/mmm would be overwritten by $:/plugins/zzz but not $:/plugins/aaa.  But I would be careful of expecting any hard and fast rules here, as I don't think the behavior is explicitly defined.  It's possible it could change between versions.

Matt

Jed Carty

unread,
Mar 18, 2019, 6:43:09 PM3/18/19
to TiddlyWiki
I Matt is correct. In the code correctly the core is added first then the other plugins are sorted by name and added in order from a to z then any plugins with a priority field with later tiddlers taking precedence over earlier ones.

A more detailed description of the sorting:

Plugins with a priority field set go before plugins that don't
Plugins with a priority field are sorted by their priority
Plugins without a priority field are sorted by their titles according to unicode order
The core

then plugins are added from the bottom to the top, new tiddlers override existing tiddlers.

If you want to see more the function that does the sorting starts on line 1122 of boot.js

TonyM

unread,
Mar 19, 2019, 3:03:39 AM3/19/19
to TiddlyWiki
A suggestion,

Examine the changes both plugins make to the shadow tiddler and construct a third that incorporates both changes and add it to your package so it is applied last. This condition is only true when you use your package so it makes sense.

To do this take a vanila wiki, an use a compare function to see what each plugin changes. Add the two changes to one tiddler.

Regards
Tony

mauloop

unread,
Mar 19, 2019, 3:17:15 AM3/19/19
to TiddlyWiki
Thanks, Matt and Jed. You've been very kind and exhaustive.

Now it's clear to me what happened and why I had to force priority for certain tiddlers and not for others.

Regards, )+(

TonyM

unread,
Mar 19, 2019, 3:21:27 AM3/19/19
to TiddlyWiki
Looks like this issue may be reduced in future https://groups.google.com/forum/?hl=en#!topic/tiddlywiki/zpzMoGUGM0g
If the difference is about widget changes.

Regards
Tony

On Sunday, March 17, 2019 at 4:09:25 AM UTC+11, mauloop wrote:

mauloop

unread,
Mar 19, 2019, 11:31:06 AM3/19/19
to TiddlyWiki
Hi Tony,


Examine the changes both plugins make to the shadow tiddler and construct a third that incorporates both changes and add it to your package so it is applied last. This condition is only true when you use your package so it makes sense.

Your suggestion is good, but not very practical for my use case, even if the involved plugins are both self-made plugins. I keep plugins separated because some of them are intended for a general use (and hopefully one day I will share them with the wonderful folk of this group  ;^))), while other are intended as customizations for very specific implementations. Your approach leads to have many different plugins with similar features, making it hard to remember which one has the latest version of a certain tiddler.

Moreover, in some cases I had tiddlers overriding shadow tiddlers from 3rd party plugins. As an example, I changed the default view and edit template for fullscreen tiddler editor of Tiddlymap. I choose to pack my customization into plugin, to avoid the need to replicate the same tiddlers for all of the wikis where I need it. It worked because "felixhayashi" comes before "mau", but as you can see this is not guaranteed.

Tiddlymap does not define a plugin priority and this is the same for most of the non/core plugins. Therefore, forcing an high priority to my plugins is not the way (plugins without priority come after a priority 100). The only consistent approach I can imagine by now is to rename myself... zzmau!!!

It could be useful to have a chance to define a priority list (more or less as the lists in $:/tags/ViewTemplate or $:/tags/EditTemplate, which gives the order to load tiddlers components). Another way (closer to my use case) could be the order used to list plugins in tiddlywiki.info

Maybe this could be matter for a feature request. 

)+(

mauloop

unread,
Mar 19, 2019, 12:08:24 PM3/19/19
to TiddlyWiki
Last minute thought.

Why not to invert the logic in the core (two lines in the code of boot.js):
  1. core
  2. plugins with no priority defined in alphabetical order
  3. plugins with priority defined ordered ascending by priority
This way one would have the chance to force plugin precedence changing the priority of his own plugin, while now this isn't possible, unless renaming. 
 







@TiddlyTweeter

unread,
Mar 19, 2019, 12:18:37 PM3/19/19
to TiddlyWiki
Isn't the issue here overwrite priority?

I found that PMario's Bundler plugin good for that since it can force overwrite. Of course you need do it in the correct order. Which is what, in a way, you are saying. 

My point is do you need bother with a new plugin at all when JSON import can overwrite easily. Seems easy, lightweight and doable?

Josiah


mauloop

unread,
Mar 19, 2019, 1:17:04 PM3/19/19
to TiddlyWiki
Dear TiddlyTweeter,

You are correct and JSON bundle could be a practical way to solve the issue once or few times.
Actually I have many wikis where I need to load the same customization. Therefore I need to maintain it in a single place and share with many wikis. I found two ways to achieve this goal:
  1. collecting all of the customizations in a separated wiki and then add it to the includeWikis section in tiddliwiki.info of other wikis
  2. packing my customizations in a plugin, add it to the tiddlywiki/plugins folder and load the plugins in other wikis via tiddlywiki.info
The first one works without priority related issues, so it can be the right way. I still wanted to test option 2 and fell into to the issue related to this thread.  I'm insisting to discuss about priority policy because I found that maybe they could be improved and I was interested to know other group members opinion.

If I am right and the priority policy could be improved, why not? despite there is a valid alternative that fit my need.

On the other hand, any suggestion is welcome. Do you know any way, other than the ones I mentioned, to keep bundles in a single place and share them between other wikis?

Thanks for your patience, )+(
Reply all
Reply to author
Forward
0 new messages