Could we interrogate the current published version of tiddlywiki? Developer discussion

Developers
#1

I have further improved a quick and easy mechanism to upgrade my wikis, especially local file wikis. This in part because we have a few versions released of late all of which have some consequence.

I am wondering if someone like @jeremyruston can publish somewhere, the latest tiddlywiki version, perhaps using content within tiddlywiki.com, or even in or along side the upgrade site

that we can query from any tiddlywiki in the wild and use to compare to the current tiddlywiki’s version.

If this were so I could make my quick upgrade button display only if a later version is available. It includes a mechanism to display caveats etc… before upgrade.

I can think of a “html get” that retrieves the value and populates an $/info tiddler with the latest release, each time a wiki is loaded. If we can’t have this happen on every wiki load, then perhaps every 10, or user initiated. Or after seeking permission once/each time.

  • Theoretically such information could be in a CDN and not hit the actual server much.
  • Perhaps if people gave permission we could just count the queries and get some anonymous analytics on the number of tiddlywiki loads?
    • This may be an opportunity to allow people to voluntarily help us collect instances, such as the versions numbers in use in the wild.
  • It would need to fail gracefully when off line

This is not currently within my skill set, but I can help.

  • Regardless of possible objections I think there would be a lot of people who would choose to opt-in to quickly see if they are on an older version and quickly upgrade.
  • Hosted, node and internet facing wikis need a different process, so we should also detect this and vary instructions accordingly. For example node wikis may only report there is a newer version and link to instructions where single file wikis offer a quick method (I have a working quick upgrade).

Why

  • Encourage and simplify upgrades
  • Especially when a few upgrades come rapidly, as has happened in 2023
  • Reduce complexity debugging when not on the latest version of tiddlywiki
  • Posibly gain an indication of tiddlywiki use in the wild.

Related matters;

  • It would be timely and related to add the following at the same time;
    • @EricShulman’s permalink captured in an info tiddler
    • I my (with Erics help) capturing the current window.name in an info tiddler, if available (This has powerful implications I will not detail here).
1 Like
#2

I just want to point out when I try and upgrade local file wikis with chrome the upgrade seems to take forever, however in Firefox it is almost instantaneous.

  • So long I want to terminate it and even freezes the wiki I am upgrading.
#3

With every new tiddlywiki release, tiddlywiki is published as a javascript package at npmjs.org. There is an endpoint which returns package information including the version. This code (warning, no error handling) works for me:

\procedure store-fetched-output()
<$action-log/>
<$action-setfield $tiddler="$:/temp/latest-tw-version-number" status=<<status>> statusText=<<statusText>> error=<<error>> text=<<data>> headers=<<headers>>/>
\end

\procedure fetch-latest-tw-version-number()
	<$action-sendmessage
		$message="tm-http-request"
		url="https://registry.npmjs.org/tiddlywiki/latest"
		oncompletion=<<store-fetched-output>>
	/>
\end

<$button actions=<<fetch-latest-tw-version-number>>> fetch latest tw version number </$button>

Most recent tiddlywiki version: ''<$text text={{{[{$:/temp/latest-tw-version-number}!is[blank]else[{"version": "not retrieved yet"}]jsonget[version]]}}}/>''

See the same code in action at the share site

2 Likes
#4

It’s also worth noting that another endpoint captures information on all the versions, if you ever need to deal with them. As well as the same sort of detailed information, per version, as the above, it contains several useful blocks, such as

   "time": {
        "modified": "2023-12-23T10:27:27.696Z",
        "created": "2012-07-13T16:13:19.831Z",
        "0.0.1": "2012-07-13T16:13:21.680Z",
        "5.0.0-alpha.4": "2012-07-13T16:39:11.697Z",
        "5.0.0-alpha.5": "2012-07-13T16:51:43.621Z",
        "5.0.0-alpha.6": "2012-07-13T17:04:44.178Z",
        "5.0.0-alpha.7": "2012-07-13T17:14:29.649Z",
        "5.0.0-alpha.9": "2013-03-27T11:22:09.507Z",
        "5.0.0-alpha.10": "2013-08-27T15:47:22.838Z",
        "5.0.0-alpha.12": "2013-11-08T21:41:53.254Z",
        "5.0.0-alpha.13": "2013-11-09T19:27:53.541Z",
        "5.0.0-alpha.14": "2013-11-10T23:16:09.514Z",
        "5.0.0-alpha.15": "2013-11-19T12:21:36.047Z",
        "5.0.0-alpha.16": "2013-11-30T13:26:08.941Z",
        "5.0.0-alpha.17": "2013-11-30T15:19:36.916Z",
        "5.0.1": "2013-12-06T17:34:28.725Z",
        "5.0.1-alpha": "2013-12-06T17:51:50.133Z",
        "5.0.2-beta": "2013-12-15T14:35:45.328Z",
        "5.0.3-beta": "2013-12-15T17:00:52.655Z",
        "5.0.4-beta": "2013-12-22T15:48:49.730Z",
        "5.0.5-beta": "2013-12-24T14:22:55.957Z",
        "5.0.6-beta": "2014-01-03T17:17:09.071Z",
        "5.0.7-beta": "2014-01-26T21:05:25.997Z",
        "5.0.8-beta": "2014-02-28T15:55:51.962Z",
        "5.0.9-beta": "2014-04-15T20:44:05.236Z",
        "5.0.10-beta": "2014-04-19T13:07:58.324Z",
        "5.0.11-beta": "2014-05-16T13:55:12.695Z",
        "5.0.12-beta": "2014-05-17T00:16:42.354Z",
        "5.0.13-beta": "2014-06-24T09:45:00.216Z",
        "5.0.14-beta": "2014-08-13T16:11:50.660Z",
        "5.0.15-beta": "2014-08-20T21:57:43.099Z",
        "5.0.16-beta": "2014-09-02T13:00:53.868Z",
        "5.0.17-beta": "2014-09-12T16:51:44.639Z",
        "5.0.18-beta": "2014-09-17T21:19:08.997Z",
        "5.1.0": "2014-09-20T16:54:02.249Z",
        "5.1.1": "2014-09-22T11:07:07.216Z",
        "5.1.2": "2014-09-27T16:35:23.924Z",
        "5.1.3": "2014-10-20T17:16:15.848Z",
        "5.1.4": "2014-10-22T16:01:12.782Z",
        "5.1.5": "2014-11-26T16:11:04.636Z",
        "5.1.6": "2014-12-19T15:58:46.538Z",
        "5.1.7": "2014-12-19T22:14:14.194Z",
        "5.1.8": "2015-04-17T16:38:35.563Z",
        "5.1.9": "2015-07-03T15:48:35.345Z",
        "5.1.10": "2016-01-07T23:27:37.602Z",
        "5.1.11": "2016-01-30T14:28:29.626Z",
        "5.1.12": "2016-07-13T10:50:54.372Z",
        "5.1.13": "2016-07-25T08:51:54.599Z",
        "5.1.14": "2017-04-26T16:04:15.446Z",
        "5.1.15": "2017-11-14T12:35:25.873Z",
        "5.1.16": "2018-04-25T17:37:03.969Z",
        "5.1.17": "2018-05-12T10:49:49.762Z",
        "5.1.18": "2018-12-06T09:05:25.293Z",
        "5.1.19": "2018-12-20T16:43:48.779Z",
        "5.1.20": "2019-08-09T13:29:19.777Z",
        "5.1.21": "2019-09-10T15:33:10.276Z",
        "5.1.22": "2020-04-15T15:15:03.210Z",
        "5.1.23": "2020-12-24T13:39:15.435Z",
        "5.2.0": "2021-10-03T14:29:44.636Z",
        "5.2.1": "2021-12-08T12:18:22.175Z",
        "5.2.2": "2022-03-25T14:00:19.530Z",
        "5.2.3": "2022-08-02T11:32:29.662Z",
        "5.2.4": "2022-12-13T16:36:13.780Z",
        "5.2.5": "2022-12-19T18:48:49.920Z",
        "5.2.6": "2023-03-20T18:51:59.826Z",
        "5.2.7": "2023-03-26T07:51:11.284Z",
        "5.3.0": "2023-07-01T11:42:25.365Z",
        "5.3.1": "2023-08-20T10:38:27.985Z",
        "5.3.2": "2023-12-13T08:12:31.077Z",
        "5.3.3": "2023-12-23T10:27:27.520Z"
    },
3 Likes
#5

@Scott_Sauyet

So we could even determin how old and how many versions old a current wiki is.

Thanks for this @btheado I will review today :nerd_face:

#6

So you think it resonable to get the latest version number using this in a startup action?

  • I would also ask if it would make sense in the default distribution?
#7

The problem we have to be careful about is that retrieving the latest version number from tiddlywiki.com results in network traffic that can be observed by others. In fact, the version number check would be like a beacon, lighting up everytime somebody starts TiddlyWiki.

So, doing these checks automatically is definitely not an option for the core, but we could consider a check that requires explicit manual initiation.

1 Like
#8

A user invoked check for update, could report the value and save it. Whether or not they do upgrade. We could then link this to an improved update button which I can describe in more detail later, it also gives us the opportunity to present information about backups and upgrades.

  • Could we provide a simple option to check at a user nominated interval, such as 3 or 6 monthly?
  • Then when we visit a less frequently used wiki we will be told, it is an older version, this would help sometimes when starting to use the wiki.
#9

Hi @TW_Tones

This could be done very easily as a wikitext startup action but I think it should be plugin territory. An automated check that runs whenever the wiki is visited in the browser would be irritating and/or irrelevant for users who were just visiting a wiki to read the content.

#10

@jeremyruston Oh. My error. Thanks for the feedback.

I just realised I was coming from a specific context quite different from a general audience.

  • No need to advise a user that someone else’s wiki is versions behind or even check the latest release.

My primary use of tiddlywiki is running a dozen or more private wikis for my own use, all of which I can edit and save.

  • Some I visit and edit the content daily and others less often.
  • Some I visit regularly and write tiddlywiki script, and others also less often.
    • It’s only when coding a change is it important to be aware if it’s release version is older than the most recent.
  • When a new release is available, that is “the current wiki is on an older version”, I would like to be prompted, rather than have to go looking. Especially in wikis I have not visited for a while.

Conclusion

I have the mechanism now to implement this thanks to @btheado, and will do so and explore the best way to use it in my own wikis, and then explore it’s validity to a wider audience.

Perhaps something like this;

  • Only check if the wiki editor opts in
  • Only check every month or two, and then only if the wiki gets saved and reloaded.
  • Once a check occurs record the latest release found, and the date it was found/released, but don’t check again for N saves, or N months
#11

Ah. “Phoning home”.

That’s okay. Tiddlywiki is Home.

did I really just say that out loud? :blush:

#12

For me personally there is no need to update a wiki as long as it works as expected. If there are new features in TW that I need in my wiki, I do an update.

So the motto is: “If it ain’t broke, don’t fix it”

just a thought
-m

2 Likes
#13

I think the value of such a feature is to be determined by the user and the use case.

  • I just want the feature available.

I have a number of wikis I used to develop concepts and build solutions and packages on tiddlywiki. I often find that features in a new release alow me to solve long standing problems, so I Typicaly want the wikis at the latest version.

I have found a number of times recently I have to add something to a project and get unexpected results. Until I realise its not at a recent release.

Also, on interactive wikis I prefer to upgrade to the latest version when adding and modifying tiddlywiki script because if I dont sooner or later, I do have to upgrade to the latest, and if something went wrong it would be harder to trouble shoot a bigger version jump.

  • This is particularly with 5.3.0 and its subsequent rapid fix releases. A lot was not supported in 5.2.x and at present the latest version is the best.
#14

I just realised I could use something similar to retrieve the version number of my own packages but how to do it I am not so sure. But it would be nice.

  • I already have the package tiddler name, version fieldname and the address of the wiki, which owns a given package, and they are typically single file wikis.
  • I could update a package with a click, wow.

[[Edited]]

And following on from this, I could publish the latest TiddlyWiki version at my own address and allow my wikis to poll this on load, not only will this do as I wish while keeping it private I also get to look at my own usage statistics.

  • I would need a way to stop this if the wiki is no longer at my published address, or is not me.
#15

You could try tm-http-request like this and get yourself a secure endpoint using ngrok.

#16

It is just as simple to host a file on a php site and pull the value from there?

#17

Any site providing an endpoint/API will do. You expressed concern about security. ngrok will let setup a secure tunnel that (assuming you don’t publish it anywhere) is purely for you.

That said, you could…