The Tiddlywiki update facility

The project we are putting together will involve a master wiki and slaves, one slave for each editorial team member. So I am looking at any method for merging slaves into the master.

I like the online Tiddlywiki update facility and wonder if a version of it is available for me to implement for our wiki?

Bobj

I think you mean the TW plugin update mechanism, which is used for shadow tiddlers, which start with $:/ so they are invisible for most default TW functions.

So IMO that’s not really what you need.

Bob,
Someone else is going to give you better advice, I’m sure. But if you need a quick, easy solution, I’ll tell you what I’d do:

I would have a time stamp attached to each of the files (slaves and masters alike). The slaves might have identifiers but I would try to get away from having them with individuals’ names on them. The master would have “-Master” somewhere in the file name: 202506-072220-202506-072219-ProjectTW-Master. Note the two date stamps: the first being the update and the second being the “thread” or “version” (I don’t mean the TW version; rather: YOUR team’s TW version).

The slaves would have something like: 202506-072203-202506-072219-ProjectTW-25 (25 denoting the team member). You, if you are the leader, could have “1” for your own slave version.

Team members (slaves, including you) can upload your slave versions to the server or other storage. That would mean a lot of backups and versions. But you would know which ones are the later versions from the file names. They would never be overwritten. Just archived.

But to resolve this issue of having slave TWs having tiddlers that are not in the latest “-Master” TW, I would ask that all team members (including yourself) “dump” all the latest relevant tiddlers onto the file server as well (JSON files), which, in turn have their own "time stamps, -Master /-Slave, title". What you’ll get is a tonne of tiddlers and TWs on the server. But when you update the “-Master” tiddler, you’ll know which tiddler JSONs to pick from.

Everyone on the team would have access to the latest “-Master TW” and could themselves compare whether their “relevant” tiddlers made it successfully to the “-Master”.

It is, in fact what I do personally, even though I’m the only active “team” member. (Like everyone else here, I use multiple computers and devices. But unlike everyone else I DO NOT USE CLOUD or server storage.) The other member being my wife, who has little interest in TWing. :slight_smile:

You’ll soon get a genius coding /script solution and possibly a plugin solution that’s way better than the one above. But, this is my two cents.

@pmario , you are right, I don’t need the shadow tiddlers updated. But can the facility be altered so user tiddlers are updated?

Bobj

Thanks @AlfieA . Your comments are along the line I was thinking about.

Bobj

1 Like

Give your TWs hassle-free updated names:
Save Your TiddlyWikis Without A Saver Or Plugin - Tips & Tricks - Talk TW

And in the “New Tiddler Titles” in the control panel, you can have the same syntax <<now YYYY0MM-0DD0hh0mm>>-202506-072345-ProjectTW-1

Just to complete the feedback.

I have used code from @EricShulman, Export multiple tiddlers in one file selected by tag of field - #4 by EricShulman, as suggested by @tw-FRed in the discusion, JSON exporting of tiddlers - #3 by tw-FRed, and created an export tiddler that will export all changed tiddlers from ‘x’ days ago, where ‘x’ is provided by the user in a simple form.

Note, in the code below, you will need to change tho two filter attributes to suit your own environment.

This facility will export all changes to a JSON file so you can share these changes with others. Just enter the number of day's changes you want and click the button below. If you want everything, enter -99999

For how many days ago <$edit-text tiddler="$:/temp/daysago" tag="input" default="-1"/>

Number of records to be exported is: <$count filter="[tag[All Guns]days{$:/temp/daysago}] [tag[Image Link]days{$:/temp/daysago}] [tag[Footnote]days{$:/temp/daysago}]" />

<$button> export selected tiddlers
	<$action-sendmessage $message="tm-download-file"
		$param="$:/core/templates/exporters/JsonFile"
		exportFilter="[tag[All Guns]days{$:/temp/daysago}] [tag[Image Link]days{$:/temp/daysago}] [tag[Footnote]days{$:/temp/daysago}]"
		filename="tiddlers.json"/>
</$button> 

This will allow me to have users email a JSON file of changes to me so I can import them into the master copy of the wiki.
Not tested as yet but it is expected to be OK (I hope)

Thanks for all help provided.

bobj

2 Likes

Nicely done!

Here’s a few refinements:

\define temp()		$:/temp/MyExport
\define filter()	[tag[All Guns]] [tag[Image Link]] [tag[Footnote]]
\define daysago()	1

<pre>This facility will export all changes to a JSON file so you can share these changes with others.
Just enter the number of day's changes you want and click the button below.
If you want everything, enter 99999.</pre>

Select all changes matching:<br/>
<$edit-text tiddler=<<temp>> field=filter default=<<filter>> placeholder=<<filter>>/><br/>
For how many days ago:<br/>
<$edit-text tiddler=<<temp>> field=daysago default=<<daysago>> placeholder=<<daysago>>/>

<$let filter={{{ [<temp>get[filter]else<filter>] }}}
     daysago={{{ [<temp>get[daysago]else<daysago>] +[multiply[-1]] }}}>
<$set name=tids filter="[subfilter<filter>days<daysago>]">
<$count filter=<<tids>>/> matching items found
<ol><$list filter=<<tids>>><li><$link/></li></$list></ol>
<$list filter="[<tids>!match[]]">
	<$button>export matching items
		<$action-sendmessage $message="tm-download-file"
			$param="$:/core/templates/exporters/JsonFile"
			exportFilter=<<tids>> filename="tiddlers.json"/>
	</$button>
</$list>

Notes:

  • For convenience, the temp tiddler title and the default filter and daysago values are defined at the beginning of the tiddler. This makes it easy to change these values in the future.
  • The “help text” is enclosed in a <pre>...</pre> wrapper to make it more visually distinctive (and also retain line breaks).
  • The filter is an input, so it can be readily changed. Note that the filter does NOT include the days operator. This will be applied later on.
  • The daysago input is entered as a positive number. The negative sign is applied later on.
  • The filter and daysago inputs are then retrieved as variables with fallback to their defaults if nothing was entered.
  • The daysago variable is also multiplied by [-1] for use in the days operator.
  • The list of matching tiddler titles is retrieved once and stored in a variable (tids). This saves on further computational overhead and is also needed for use in the “tm-download-file” message. Note that using the $set widget returns the entire list of matching titles and automatically adds doubled square brackets around any titles that contain spaces.
  • The count of matching items then uses <<tids>> as the filter
  • A numbered bullet list of matching items is also displayed using <<tids>> as the filter.
  • The “export matching items” button is only displayed if matching items were found.
  • The exportFilter param uses <<tids>> to pass the list of tiddlers to the “tm-download-file” message.

enjoy,
-e

4 Likes

6 posts were split to a new topic: Fallback handling for $image widget

Just a suggestion if your “data tiddlers” are time stamped you could also modify the import mechanisium to selectivly import based on both the import titdlers data and time and by comparison with the time date in the master wiki.

  • That is this kind of selection can be done either or both sides of the export/import process.

Further there are ways to share what I call a data plugin, ie a plugin which contains data not code (any tiddler names permitted) this is then given to a slave wiki. Should that wiki edit an existing data tiddler it looses its only a shadow status, and if new tiddlers are created that match the same filter its easy to generate an export or even new plugin of only the changes. These are then sent to the master (Changes only) a special kind of change could be a delete request.

  • This changes only import on the master could be designed to support a smart import to assist when two slaves try and change the same tiddler.

Another technique is to structure the data from each slave to arrive with a prefix for each slave source wiki. There will never be a direct clash with other slaves or the master.

  • Various methods can then be used when searching accross all slaves (there data in the master) or in reporting.

Special Note:

All of which I suggest above is quite easy with TiddlyWiki tech however there are no out of the box tools, primatives, hacks or supporting widgets or tools so it proves to be more complex than would be desirable.

  • In reality some of these could be created once and used by the community many times. So this would be a great project.

Not sure I appreciate all you say.

Bobj

Yes, the subject is “Bigger than Ben Hurr”. I did not have an hour to write the extended version. If it hints at an approach you need I can expand.

  • Eventualy I will likely publish such tools but I would not wait :nerd_face:

Hi !
This is not exactly what you asked for, but I still share it because it could maybe be useful.

I am using git/GitHub to work on a TiddlyWiki with someone else, and I build a system so I can commit/push and manage merge conflicts inside the wiki.
I didn’t update the GitHub repository but there are improvements on the wiki I am currently using, so tell me if it could be helpful and I will update it.

2 Likes