Your help is needed to test v5.4.0

Date will be adjusted - Pinned till 31st April 2026 for the moment

Especially important is the Impacts tab, since it documents incompatibilities and deprecations. That’s important to test with your 3rd party plugins.

5 posts were split to a new topic: V5.4.0 prerelease - Problems with text-reference transclusions

4 posts were split to a new topic: V5.4.0 prerelease - Import is much slower now

It seems Uglify from @Flibbles does not work with new release. This is uglified empty.html with few tiddlers

Relink won’t work either. Not with any new syntax.

If I had known that by making those plugins, I was signing myself up for perpetual updates with every major release of TW, I… I probably still would have done it. I have a problem.

But those plugins will have to wait a minute. I’m working on other stuff right now. Taking a TW break for a while.

10 Likes

3 posts were split to a new topic: Test locally built empty.html with prerelease libraries

3 posts were split to a new topic: V5.4.0 prerelease - Zoomin Story View - Close All triggers RSOD

4 posts were split to a new topic: 5.4.0 prerelease - Code lines pre-wrap setting as default

Tested on my main wiki and nothing looks broken.
Not having the tidgraph problem reported above.

2 posts were split to a new topic: V5.4.0 prerelease - Inconsistency in Call Documentation

3 posts were split to a new topic: V5.4.0 prerelease - Clearifications about MVVs using with various operators

2 posts were split to a new topic: V5.4.0 prerelease - Simple Search Plugin Seems to Have a Problem

2 posts were split to a new topic: V.5.4.0 prerelease - link-to-tabs Plugin Link Icon has Wrong Colour

3 posts were split to a new topic: V5.4.0 prerelease - Several block-quote syntax blocks are slow

A few notes I’ve found running the updater against my wiki. 5.4.0 RSOEs my wiki currently:

  • the “Vis” plugin from @Flibbles’s graph plugin complains when updating a wiki (but I can’t reproduce in the sample for that plugin):
[Error] Script error.
	(anonymous function) (upgrade-4.html:5208)
	(anonymous function) (upgrade-4.html:5260)
	(anonymous function) ($:/plugins/flibbles/vis-network/vis.js:39)
  • Maybe related, or unrelated, but I hit an error in the transclusion widget immediately after:
[Error] ReferenceError: Can't find variable: alt
	(anonymous function) ($:/core/modules/widgets/transclude.js:462)
	(anonymous function) ($:/core/modules/widgets/widget.js:691)
	(anonymous function) ($:/core/modules/widgets/element.js:83)
	(anonymous function) ($:/core/modules/widgets/widget.js:691)
	(anonymous function) ($:/core/modules/widgets/widget.js:72)
	(anonymous function) ($:/core/modules/startup/render.js:72)
	(anonymous function) ($:/core/modules/startup/render.js:74)
	(anonymous function) (upgrade-4.html:7640)
	(anonymous function) (upgrade-4.html:7587)
	(anonymous function) (upgrade-4.html:7597)
	(anonymous function) (upgrade-4.html:7777)
	(anonymous function) (upgrade-4.html:6782)
	(anonymous function) (upgrade-4.html:7775)
	_boot (upgrade-4.html:7784)
	Global Code (upgrade-4.html:7796)

I’ll see if I can get a minimal reproducing case for this (this is a private wiki).

2 posts were split to a new topic: V5.4.0 prerelease - Quick Image Plugin causes EditTemplate Problem

3 posts were split to a new topic: V5.4.0 prerelease - Markdown plugin causes RSOD

If by any chance you use the markdown plugin, this error about the alt variable may be related to an issue I just patched.

5 posts were split to a new topic: V5.4.0 prerelease - Performance Regression Using List Filters in ViewTemplate

Can we talk about Relink for a second?

I’ve just frozen the current version of Relink to TiddlyWiki <=v5.3.8. There are too many finnicky changes to wikiparsing for me to put in the time making Relink compatible pre and post v5.4.0.

But since I’m doing that, it means Relink might take advantage of new TW mechanics. But I’ve got some questions about it. I don’t have time to upgrade Relink just yet, but I’m looking at the core code now, and it doesn’t look like it’s in good enough shape yet for a new and improved relink—the kind you all deserve.

“Core plugin to serialize syntax trees back to strings”

This would be great… if it’s done right. Relink goes to a lot of trouble making its own wikiparser hybrids because it could never rely on converting to a parse tree and back.

It’s looking like this feature is only good for when the parse tree is exactly the same as it was. I’m seeing a lot of “start” and “end” stuff. But those get pretty useless to me quickly if Relink needs to 1) swap out a title with one of a different length, 2) change quotation on some attribute, or 3) downgrade a wikilink into a transclusion or something like that. Everything will get offset.

Is tracking offset just something I’ll need to contend with?

It doesn’t look like the parse tree remembers the kinds of quotes used. When you guys are “reverting” parse trees back into text, are you changing all the quotes the user chose to use? Or are you looking at the offsets?

Bulkops has not changed in 4 years.

One thing people have always disliked about Relink is that it uses startup modules to inject new code into bulkops—the wikimethod module that introduces the core relinking behavior for tags and list.

Relink does this because there is no other mechanism to do so properly. So Relink will still be blasting parts of bulkops and making itself incompatible with any other plugins that might want to introduce their own renaming behavior independent of Relink.

Is this fine with everyone? Or do we want to update this?

\Define and $depth

These two “features” are the two reasons Relink can never truly be a 100% relink solution. \define makes the wikitext too unpredictable. And $depth makes it impossible to know where parameters are coming from, and thus if they should be relinked.

\define is an old dog whose served us well, and I also know it probably can’t be removed yet. But $depth… ohhh. I’ve got bones to pick with that attribute

I know @jeremyruston agreed to deprecate it, at least for the <$parameters> widget (<$slot> doesn’t have a better alternative yet). Can we do that? Can we remove this monstrosity? I stand by my assertion that no one is using it, because no one knows how. It’s a terrible antipattern.

Edit: Sorry to everyone I’m bothering by asking. I know a lot of these questions are ones I could answer myself if I dug into the source more, but I’m in the middle of an unrelated time-constrained project, and might not have time to really jump into Relink again until after v5.4 releases.

9 Likes