Make overwrites unproblematic! (in 5.4.0?)

[twMat]

"The best thing with TW is that you can modify it to your needs!"

...but overwriting shadow tiddlers can cause problems because updates of the shadow tiddlers don't take effect and may have unintended consequences.

Clearly a conflict!

Even abiding users can naïvely and unknowingly be subjects to this problem; In spite of never overwriting anything themselves, they may have installed plugins (from others) with shadow tids that are really overwrites of core tiddlers!

My Overwrite plugin addresses this problem to some extent. Basically, for every overwrite it lets the user create a hash code (sha256[]) for the underlying shadow. Then if the shadow is updated, its hash is compared to the stored hash and an alert is sent if they don't match. Since merely a hash number is stored, it is a pretty efficient approach, I think.

The alert prompts the user to compare the overwrite with the new shadow, simply using the editview diff comparison - so the user can either dismiss the alert, modify the overwrite or simply delete it. An alternative could be to, in the plugin list, mark out plugins that need updating to match the new core version (and subplugins to match their main plugin).

Proposal
In the name of maximum TW modifiability, I propose that TW natively features alerts for updated shadows with overwrites. I think it the outlined approach could work. A problem is this:

What should trigger the storing of the hash?
At first glance it may seem that saving an overwrite, i.e clicking the overwrite "save tiddler"-button, should trigger the storing. But not every overwrite involves such manual saving. In the Overwrite plugin I made a central "shapshot" button to create+store the hash for all overwritten shadows; The user is to click this at some time, ideally just before updating his wiki. OK, but not optimal. A possibly better idea could be to have the Import mechanism button first triggers the storing of the hashes. (Would this work when upgrading the core via the tw/upgrade site?)

Note: It is neat that the stored hash potentially remains unchanged for years and years, through core updates, for as long as the concerned single shadow tiddler is not modified.

Whaddyasay? Doable? Already for 5.4.0 ?

[pmario]

I think that's a great idea and it is very well executed. -- But -- I am not sure, if it is easy to make it "automagically"

• We already know if a shadow is overwritten with [is[tiddler]is[shadow]sort[title]]
• We show some info if an overwritten shadow tiddler is edited.
  • We know the plugin, where it came from
  • 
• Sometimes (several) plugins may overwrite a shadow tiddler
  • If several plugins are involved, that may cause a problem. -> IMO it's an edge-case which may need special handling
  • If plugins overwrite a shadow, it will stay a shadow -> Not sure if that's a problem
• $:/config/ tiddlers are designed to be overwritten -> Do they need an info too?

---

• There is a message, the first time a user tries to edit a shadow tiddler
• We could use that one to create a "fingerprint" (sha256) of the shadow and write it to the "clone"
  • may be fingerprint-shadow

At startup we would need to check all tiddlers with a fingerprint-shadow and compare it to the "fingerprint" of the original shadow tiddler. If they are different show some warnings and info how to resolve the potential problem. eg: If the tiddler has been saved, but not changed there should be an info, that this tiddler can probably be removed without side effects. (See edge cases!!)

Assuming the number of overwritten shadows is small, that should not be a startup performance problem.

Just some ideas. -- Edge cases are not dealt with at that moment.

[pmario]

We will have a closer look at Themes and Language plugins - They may cause "edge cases" too.

[twMat]

I don't think they'd be any different from other plugins?

[pmario]

IMO related to: Strategy for documenting backwards compatibity breaks #9142

[twMat]

Edge cases are not dealt with at the moment

Maybe that's exactly what I'll do here so FWIW:

We already know if a shadow is overwritten with [is[tiddler]is[shadow]sort[title]]

Not quite; Yes, if an overwrite is created by a user it is a tiddler and there's also a shadow with the same name. But an overwrite can have been packaged into a plugin, in which case it is now a real shadow tiddler (...and the wiki has two real shadows tiddlers with the same name but different content! BTW, TW has some priority mechanism here, right? E.g "last call wins"?)

BUT, to at least "do the OP" for the core it would be simple to identify such non-core plugin shadows copies because they're prefixed $:/core

$:/config/ tiddlers are designed to be overwritten -> Do they need an info too?

In my Overwrite plugin, I have an exceptions list that don't cause alerts, which the user can also modify.

There is a message, the first time a user tries to edit a shadow tiddler

Only if the open the tiddler manually but they might overwrite it remotely.

My conclusion, as stated in the OP, is that the Import mechanism is the perfect place - and time - for this mechanism. But I'm not sure if there's a problem with this for when the full TW is dragged on to the upgrade page.

[twMat]

Questions:

The $:/import-tiddler uses the tiddler $:/core/ui/ViewTemplate/body/import where the [Import] button is found:

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

As indicated previously, I want to add some actions to happen when this button is clicked; What would be the best way to do this? Perhaps to add a actions={{myactions}} attribute? Would those execute before the message is executed?

As noted, I think this is the optimal place and time for storing the sha256 values of the existing plugin shadow overwrites, i.e just before the new updated plugin replaces them. Are there arguments against this? The only argument I can think of is if there are other ways to import, bypassing the above mentioned button in the $:/import tiddler. - Is there?

It would be ironic if this solution to "Making overwrites unproblematic" itself required an overwritten import mechanism. So, @Jermolene , could the import button somehow be modified in the core to allow for this action to be added to the button?

---

For anyone wanting to test outlined approach in the OP, here's how to get the text from the actual shadow tiddler (i.e not its overwrite).

<$set name=shadowtext
	tiddler={{{ ...the-overwrite-title... +[shadowsource[]] }}}
	subtiddler="the-overwrite-title"
	field=text 
>

Again, its sha256[] string would then be stored and then compared to the incoming sha of the new shadow when a plugin is updated. Different shas = the shadow has been updated, so - alert - the overwrite needs review.

[Jermolene]

It would be ironic if this solution to "Making overwrites unproblematic" itself required an overwritten import mechanism. So, @Jermolene , could the import button somehow be modified in the core to allow for this action to be added to the button?

Without core changes I suspect your best bet is to make a view template segment that is only displayed for the $:/Import tiddler with a button that kicks off your custom logic, operating directly on the subtiddlers within the $:/Import plugin.

[twMat]

OK, I hear ya. I've fiddled around with an overwriting solution soon to be published and will see how it plays out but the separate view template might be a decent route otherwise. Thank you.

[twMat]

Turns out I alerted about this already in #5518