Can anyone tell me the status of Relink plugin on TiddlyWiki 5.4.x?
Relink features are critical on all but my simplest wikis.
As raised by me but there is no clear response.
Please edit this post to add critical details, discussions etc…
Currently suggests no compatibility
| Version | 2.5.3 |
|---|---|
| Build date | March 1st, 2026 |
| TW5 compatibility | 5.1.22 - 5.3.8 |
I can confirm that Relink 2.5.3 throws (largely non-fatal) RSOEs in my 5.4.0 wiki. I’ve disabled it for the time being, and temporarily removed most instances of relink:... operators in my templates.
I think @Flibbles remains the only one qualified to give us any real status updates, but I imagine updating Relink to handle the new syntax is a quite an undertaking.
I would be surprised if there is much to change, the problem is identifying what. I did raise concerns about the key integration point in tiddlers during the rename. the original version needed to alter some core tiddlers, where a hook or hackability could have been made to support it.
I would be happy to be involved in uncovering and fixing this within my skill set, and an LLM in the analysis and discovery.
@Flibbles has understandably raised concerns about being forced into being a sole provider and maintainer of this plugin.
I did see talk of integrating it into the core plugin set and believe a few of its features (not sure which) have already being moved into the core.
This and Timimi need core team support lest TiddlyWiki fail to meet expectations in my view.
I’d be curious as to your experience please @Scott_Sauyet, having recently shipped Tidbits with Relink on 5.4.0.
Not that the latest release was March 1st, 2026 and @Flibbles was concerned. Perhaps @Flibbles could let us know the status.
The Following Question and Answer is with ChatGPT and is useful.
Please review GitHub - flibbles/tw5-relink: Tiddlywiki5 plugin to better update all other tiddlers when renaming a tiddler. · GitHub and identify possible issues with it running on top of TiddlyWiki version 5.4.0
Relink is not currently declared compatible with TiddlyWiki 5.4.0. Its plugin metadata says:
core-version: "5.1.22 - 5.3.8"(GitHub)Likely issues on 5.4.0:
Startup/core patch failure
Relink patches TiddlyWiki’s core bulk rename behaviour. The author notes it “inject[s] new code into bulkops,” and that this is inherently incompatible with other rename handlers and core changes. (Talk TW)Wikitext parser changes
The author froze Relink at<= v5.3.8because there were “too many finnicky changes to wikiparsing” for easy 5.4.0 compatibility. (Talk TW)Dynamic macro/procedure/function calls
TW 5.4.0 adds dynamic parameters to<<...>>calls, including within widget attributes and filter operands. Relink’s parsers may not recognise or safely rewrite these. (tiddlywiki.com)Multi-valued variables
TW 5.4.0 variables can now hold lists, with different retrieval forms. Relink’s variable and parameter relinking logic may treat these as single strings. (tiddlywiki.com)Syntax-tree serializer mismatch
TW 5.4.0 adds a syntax-tree serializer, but Relink’s author said Relink needs to change titles, quote styles, wikilinks/transclusions, and offsets—cases where the new serializer may not yet be sufficient. (Talk TW)Known public report
A TW 5.4.0 issue summary explicitly says: “Relink plugin does not work either. He has no time to fix it atm.” (GitHub)Practical recommendation: keep Relink-based production wikis on TW 5.3.8 for now, or test a copied wiki under 5.4.0 with Relink disabled first. For 5.4.0 compatibility, the risky area is not just one syntax bug; it is Relink’s dependence on parser internals and monkey-patching bulk rename behaviour.
this is a very good plugin indeed !
I am still waddling through my taxonomy and tags / fields etc clean-up (but getting there)
with good Wiki Taxonomy for structure + this → you basically have all blocks for LLM wiki !
maybe MCP for completeness as a better interface to TW. But not yet sure about that - as LLM can of course easily read wiki directly, as long as it knows the structure (taxonomy is well defined)
I’m workin’ on it.
I’m on Uglify first since it’s a build tool. I’ll get to Relink after that.
I would be surprised if there is much to change, the problem is identifying what.
That is the problem. I see that there are these multi-value variables which have wikitext and filter versions. Then there’s the way macrocalls use ‘=’ now instead of ‘:’???
I’m not sure what else. I mostly learn about what’s changed after everyone else has decided to change it. The macrocall changes will take time because I can’t be switching users over from ‘:’ to ‘=’ and changing their preferred style every time something relinks, so I’ve got to support both…
I don’t think you need to change your own code at all (just extend it), you can rely on the existing methods for this. They are extensions to the syntax not replacements. I think targeting where its broken should allow you to restore functionality. But yes then relink itself needs to detect and support renames within these new syntaxes, but that is something to do in the near future, not right now.
I have always felt it is amazing you extended this to macros and procedures. But I expect 90% of peoples changes relies on titles, tags and list fields being updated. Currently the majority of code exists without these new syntaxes and you have already covered that.
Thanks so much @Flibbles 
If you decide to use only the new syntax, IMO users have to agree, otherwise they can not use the tool.
IMO it is important, that you can handle it. Writing = for named parameters in macros is more consistent anyway. So IMO it should be switched as fast as possible. If you can help to encourage the update IMO the core devs would be happy.
As you know, we already have a lot of technical debt, because of our strong promise of backwards compatibility.
We have 3 commands to assign variables. Set, Vars and Let … Every one of them is slightly different and one is buggy - kind of.
IMO vars should have been eliminated for quite some time already, but I think it is not even deprecated yes
… I need to stop rambling
Just some thoughts.
Keep on with your brilliant work!
One thing powershell does that’s pretty clever to maintain a degree of backward compatibility is alias various commands or shorthand to the powershell equivalent.
For instance curl is an alias to Invoke-WebRequest. In fact now that actual curl is included in windows you have to specify curl.exe to specify it lol.
Anyways, maybe you could do something like that with some of the legacy versions of commands to maintain backwards compatibility while gently suggesting everyone moved to the new syntax? where the legacy commands are just a special “mode” or something of the newer and more robust methods?
I haven’t looked at the nitty gritty just throwing spaghetti at the wall, it might be totally infeasible
I’m kind of surprised re-link type functionality has not been baked into the core already. I use re-link so much to the point I forget it its there, and when it is not, I notice it right away and it is very frustrating working around it, which is one of the reasons I still have not updated my primary Tiddlywiki’s to 5.4.0 and will continue to stick with 5.3.8 for sometime if not permanently.
Uglify now supports v5.4.0.
Should support all new features except filter macro operand parameters, because despite TiddlyWiki claiming that’s a new feature, not even the TiddlyWiki 5.4.0 demo showcasing that feature works. And if TW doesn’t support it, neither do I. If that changes, anyone is welcome to open a github issue about it.
I’ll start on Relink soon.
Hey kinda unrelated and pardon my ignorance but as uglify is provided as its own wiki with its own gui, is there anyway to use it to programmatically uglify *.html wikis without using the UI directly? Does it support any parameters for the various uglify options?
Not sure if the best way to go about this, please let me know if you have any tips, thanks!
It doesn’t have something where you can command-line hand an html file to it and it will uglify (but in theory it could).
But it’s main purpose is to be used programmatically, so you can introduce Uglify at the stage when that html generates when you’re using NodeJS. That’s a simple as including tw5-uglify as a plugin, and anything generated or served by nodeJS will be uglified. Any settings tiddlers included in your project will take effect (and then neatly remove themselves). There is a command module so you can scan and manipulate uglify settings through the tiddlywiki command-line process.
Ok sweet; so it integrates at node.js/tiddlywiki.js build time by existing as a plugin? I’ll give that a go, thanks for the help.
-Xyvir