Your help is needed to test v5.4.0

jeremyruston · February 21, 2026, 12:40pm

We have now passed the code freeze for v5.4.0. It has been in development for long time, and has nearly 100 changes. We’ve never attempted a release this ambitious.

The first thing is to express my heartfelt thanks to everyone who has contributed to this release. The GitHub contributors are listed in the release note, but there are many, many others in the community who have provided feedback and bug reports that have shaped this release.

You can try it out here:

https://tiddlywiki.com/prerelease

Because of the large number of changes, we’ve needed to improve the presentation of change notes with categories and search, which should help you find the changes of interest.

You can upgrade your wikis here:

https://tiddlywiki.com/prerelease/upgrade.html

While there are many new features that make wikitext more expressive and efficient, there are relatively few end user changes that can be found by clicking around TiddlyWiki.

Nonetheless, it a major release because of the groundwork it lays for future improvements.

We need lots of testing before the release of v5.4.0. Everyone can help, from end users and wikitext authors to JavaScript developers.

Here are some ways that end users can help:

Perform test upgrades of your wikis and thoroughly test the features you depend on
Test end user features such as the cascade details that are now shown in the tiddler info pane

Some of the new features that need to be tested by wikitext authors:

Multi-valued variables and the :let filter run prefix
Dynamic parameters for procedure/function/macro invocations
Background actions
The new architecture for $:/info/browser/* tiddlers
Improvements to the <$diff-text> widget

You can report bugs and feedback here, or via GitHub.

Doing a good job of this sort of intensive testing is hard work, but it will pay off if it helps us have a smooth release without showstopping bugs.

We would also welcome feedback on the presentation of the release note. Is it easy enough to find out what you want to know? Are there other changes that we should be summarising?

All being well, we plan to release v5.4.0 in the second half of March.

Thank you to everyone for your help,

Best wishes

Jeremy

Mario · February 21, 2026, 6:24pm

Date will be adjusted - Pinned till 31st March 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.

Mario · February 22, 2026, 10:26pm

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

vilc · February 22, 2026, 3:11pm

I’ve test-upgraded my most used wiki.

The upgrade of single file wikis seems slightly slower than it used to be; now it takes noticeable couple of seconds to finish, whereas for the older versions (tested it v5.3.6 > v5.3.8 right now) it was almost instantaneous. Not a problem for me at this scale, but I wanted to point it out just in case this is a sign of some inefficiencies that could make problems with bigger wikis.

The only complaint I have so far is that the shadow $:/themes/tiddlywiki/vanilla/options/codewrapping text was changed from pre-wrap to pre in the core. This was an issue for me, because probably due to some of my modifications the pre setting doesn’t look well with longer code lines flowing out of the tiddler area to the right. Everything is as it used to be on the pre-wrap setting.
If the default setting was changed on purpose, I’m alright with that, I can imagine why the no wrap could be better as default.

pmario · February 22, 2026, 4:39pm

Edit: I found the PR that changed this default: [v5.4.0] Update configuration defaults by Jermolene · Pull Request #9107 · TiddlyWiki/TiddlyWiki5 · GitHub

There is some discussion too. So if you disagree with the new default – Lets us know.

Also related is PR: Fix unwrapped oveflowed code blocks not showing scroll bars when setting "Wrap long lines in code blocks" to "No" in "Theme tweaks" by Leilei332 · Pull Request #8413 · TiddlyWiki/TiddlyWiki5 · GitHub

But is did not change the default shadow. I can not find the PR, that changed this value. … That’s strange.
IMO the default should be “Wrap long lines in code blocks : Yes” … We only needed to change this one for easy testing the PR.

Long lines should look like this. … So if your wiki shows text outside of the tiddler, you need to check your Style sheet settings.

The default can be changed in

ControlPanel → Appearence → Theme Tweaks → Warp long lines in code blocks

atronoush · February 22, 2026, 5:27pm

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

Flibbles · February 22, 2026, 5:42pm

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.

atronoush · February 22, 2026, 6:52pm

I tried empty.html and then I wanted to install few plugins like highlight.js, but when you click on the add more plugings nothing happened. I had to import the plugin library from online prerelaese at: TiddlyWiki Pre-release — 5.4.0-prerelease

pmario · February 22, 2026, 9:00pm

I did just download empt.html from https://tiddlywiki.com/prerelease/#GettingStarted then the import mechanism works as expected.

From where did you download empty.html? Your screenshot looks like if you did build empt.html locally with node.

btheado · February 22, 2026, 10:23pm

I notice the same thing. For one of my wikis, it took about 20 seconds between the time I dropped the wiki onto the upgrader and the time the table labeled: “The following tiddlers will be included in the upgrade” appeared.

Dropping that same 5.3.8 wiki onto the 5.3.8 upgrader had that table appear within about 2 seconds. Maybe that isn’t a fair test since it doesn’t involve an upgrade, but I would think the import mechanism still needs to perform the same functions.

I agree with this. I strongly prefer wrapping of code blocks by default. I don’t like having to use the horizontal scrollbar on all the codebody: yes tiddlers.

But if that is the way it has to be, I can configure it in all my wikis post 5.4

diligent_path · February 23, 2026, 12:38am

I noticed that “close all” in my updated wiki causes a JavaScript error: TypeError: can't access property 'style', element is null, even with content present in $:/config/EmptyStoryMessage. It can be replicated with these actions in an empty 5.4.0:

Change the story view to “zoomin”
Click “close all” in the sidebar’s “Open” tab
Change the palette
Click “close all” again

btheado · February 23, 2026, 2:16am

The crash looks to be in code which was added in this PR:

github.com/TiddlyWiki/TiddlyWiki5

Remove css props rather than setting transition to none

TiddlyWiki:master ← CrossEye:remove-transition-rather-than-set-none

opened 01:36AM - 08 Sep 25 UTC

CrossEye

+39 -19

See the Talk discussion on [Prerelease animation](https://talk.tiddlywiki.org/t/…13461) for more background. This replaces a number of post-animations blocks that set an element's CSS `transition` property to `none` with ones that remove that style property altogether. If fixes an issue in which, after an element has been animated into the story river, `:hover` transitions stop working. Although @saqimtiaz suggested looking also at `/core/modules/utils/dom/modal.js` and at `core/modules/utils/fakedom.js`, I didn't see any necessary changes there. I did find two others, `slide.js` and `cecily.js`. Testing ------- Do we have any automated testing feature that would help demonstrate the fix? I don't know that I've ever seen a programmatic way to assert that a CSS animation runs on precipitating event. Has anyone else? One simple question ----------------------- Should we add a function so that these lines would be replaced with `$tw.utils.removeStyle(targetElement, "transition")` (or possibly `removeStyles` using an array of names)? A harder question ----------------- Should we take this time to review all such JS animation resets and replace all the `$tw.util.setStyle` calls with a property removal instead? There is a good argument to be make for doing so, but it is a substantial amount of work. And it seems as if testing would be quite difficult. Even recognizing when we're resetting to defaults rather than to arbitrary values might be difficult.

I’m able to duplicate the issue at this share site url with zoomin view preconfigured

Click the share site link and then close the only open tiddler (or click close all). The javascript error is the result.

saqimtiaz · February 23, 2026, 7:47am

@vilc @btheado could you please test this copy to see if the issues with import being slower persist? Thank you.

saqimtiaz · February 23, 2026, 8:09am

Thank you, this should now be resolved.