Announcing the release of TiddlyWiki v5.2.7

[jeremyruston]

TiddlyWiki v5.2.7 has just been released to:

https://tiddlywiki.com/

This is a bug fix release to fix a single bug that was introduced in the prior v5.2.6 release.

You can upgrade your existing single file wikis here:

https://tiddlywiki.com/upgrade.html

For Node.js users, the new version is available on npm at tiddlywiki - npm

As usual, please exercise caution when upgrading, and take care to keep backup copies of everything important.

I’d like to thank everyone who has contributed to this release.

Any questions or comments are welcome here, or via GitHub.

[Alan_101]

I think I’ve identified a compatibility issue of v5.2.7 compared to v5.2.3

This involves the Dropbox App on an iphone (iOS version 16.1.2).

When I’m vieiwing a tiddlywiki on my iphone via the dropbox app the right hand menu featuring the search bar is placed on top of the story river.

If I do a search with v5.2.3 the results of the search are fully available to me and the story river remains fixed at the bottom of the screen as I scroll up and down to view the search results which moves with my gestures.

If I do a search with v5.2.7 the results of the search are blocked by the storage river which moves with my gestures and the results display seem to be going behind the tiddlers.

To test this to make sure this wasn’t an issue with my tiddler is I created a new tiddler with sixteen Test Case xxx tiddlers and the content being testing. I then created an upgraded version of the tiddler to 5.2.7 and placed both in my dropbox. The issue is present on the upgraded version but not the original.

On a separate note which seems to exist in 5.2.3 as well as the ‘Edit this tiddler’ and ‘Close this tiddler’ icons do not appear responsive.

[pmario]

Can you replicate the problem with tiddlywiki.com? …

May be you did overwrite a UI tiddler. Also check if one of your plugins did cause the problem.

[Alan_101]

Yes, the issue is present from the downloaded version the tiddlywiki.com wiki. I should have thought about testing that first.

I should also add for clarity that this is in reference to the single file version of tiddlywiki.

[jeremyruston]

Hi @Alan_101 thank you for the report.

I first tried to replicate the problem using my iPad with iPadOS 16.4 with the Dropbox app window positioned as a “slideover” window, making it tall and thin (see first screenshot below). That worked OK, so then I tried the Dropbox app on my iPhone with iOS 16.4 and saw the problem that you describe (see second screenshot below). It seems very mysterious to get different results.

I then tried viewing tiddlywiki.com in the in-app browser in Mastodon on my iPhone, and again found that the problem was present. Then I tried the same experiment on my iPad with Mastodon in a slideover window, and again found that the problem was present. I couldn’t replicate the problem using Safari as a separate app.

These inconsistencies are frustrating. There’s no obvious differences between the iOS in-app browser and Safari.

I suspect that this is somehow related to a fix for the story river overlapping the search results dropdown on narrow screens that was included in v5.2.4 (the fix is here).

I am away from my desktop computer at the moment and so can’t use developer tools to investigate further. In the meantime, I’d welcome any further reports highlighting configurations where the problem is present.

[jwd]

A different issue that arose with 5.2.7 that I’d never encountered before (I didn’t try with 5.2.6): When I upgraded TiddlyWiki on my Synology NAS device I ran into:

`npm install tiddlywiki

npm WARN tar TAR_ENTRY_ERROR ENAMETOOLONG: name too long, open ‘/volume1/Repos/TW/node_modules/tiddlywiki/editions/zh-Hans/output/static/%22%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3%E5%88%B7%E6%96%B0%E3%80%82%E6%AC%A1%E3%81%AE25%E5%B9%B4%E3%82%92%E7%9B%AE%E6%8C%87%E3%81%99TiddlyWiki%22%20by%20Moongift.html’`

This was apparently a result of the URL encoding of the filename for “デザイン刷新。次の25年を目指すTiddlyWiki” by Moongift.html

It appears that on my Synology’s current flavor of Linux that the maximum length of a file path is 203 characters. Web searches suggest others have encountered even shorter path length limitations when using encrypted filesystems.

Something to be aware of? Might there be a way to npm install tiddlywiki for node.js without all the editions?

[pmario]

@jwd

Moongift.html’`

Moongift.html is not a TW edition.

It’s a known problem that node_module dependency nesting can cause problems with path length on windows. Linux flavours usually do not have that limitation. But it may be possible that proprietary systems have even lower limits. That’s sad

[jwd]

A misunderstanding: the mentioned file occurs in the node_modules/tiddlywiki/editions/zh-Hans/output/static directory that npm install tiddlywiki creates. The filename itself is 166 characters long on macOS, but if you combine that with the 55 characters that are going to result from the npm generated path then one is starting to approach the limits of most filesystems

[pmario]

@jwd

if you combine that with the 55 characters that are going to result from the npm generated path then one is starting to approach the limits of most filesystems

Uups. You are right. I had other numbers in mind. … Don’t know where that came from. … Anyway it’s a pain point

@jeremyruston … would need to block shipping of the output/static content, which IMO does not make much sense in the NPM package anyway.

[jeremyruston]

@pmario

@jeremyruston … would need to block shipping of the output/static content, which IMO does not make much sense in the NPM package anyway.

Thanks @jwd @pmario this is a bug. The script I use to publish to npm is supposed to delete all the output directories:

Jermolene/TiddlyWiki5/blob/master/bin/npm-publish.sh

It looks like regexp in clean.sh doesn’t match the dash in the zh-Hans edition name because it is not escaped in the regexp. I’m away from my desk but will push a fix soon.

[jwd]

taking a look at clean.sh I am not clear on why there is a complicated regex for the editions that are
cleaned, currently: find . -regex "^./editions/[a-z0-9\.-]*/output/.*" -delete

It seems to me that the simpler find . -regex "^./editions/.*/output/.*" -delete
would cover current cases of editions that leave some output as well as future editions that might use non-ASCII characters in their directory names (which seems to be the case if I create one of those.)

However I am not familiar with the innards of TiddlyWiki / npm / node that might make this
a non-issue or a problem.

[jeremyruston]

Thanks @jwd I realised the same thing when I got back to my desk. Fixed in Fix clean.sh · Jermolene/TiddlyWiki5@b1c2952 · GitHub