V5.3.2: story river fails to scroll to open linked tiddler ... why? (conflict w plugins that uglify)

I should have mentioned that there is an upgrader for the preview release here:

https://tiddlywiki5-git-trim-whitespace-after-pragmas-jermolene.vercel.app/upgrade.html

This fact is, in the prerelease for example $:/core/modules/widgets/action-navigate.js does not contain the above. Is that the same problem?

What you are seeing there is the transformations applied to JavaScript modules by the Uglify plugin. That’s why the core modules in this wiki are different than the standard ones.

Wow, thanks @jeremyruston for the close look and diagnosis!

When I post about unexpected TiddlyWiki behavior, much of the time the fault is somehow mine (mistaken css syntax somewhere, etc.). So I’m always sheepish. But when something does turn out to be an issue that could potentially affect others, I’m happy to see that proactive problem-solving on this forum can be very fast.

I easily lose track of the steps needed to re-initiate external core after an upgrade, and I do want to re-introduce external-core mode eventually… (I am happy to wait until @simon sets up an external core template at tiddlyhost for the upcoming version.) At any rate, I’ll keep this project as internal-core for a while, just to be confident that the problem does not re-appear (as @CodaCoder had this behavior come and go, and it seemed to show up or not show up rather randomly in my experiments).

Thanks!

I’m like a cat watching ping-pong here. This has been fascinating. I did start comparing all the settings between the two wikis. And every time I found a difference: “Aha”, only to have it not fix the issue. I could never have found what Jeremy determined… which reinforces for me how much further I have to go in my journey.

Did you ever figure out what plugin was introducing Uglify?

1 Like

I recall from some earlier exchanges here that uglify is incorporated in some plugins by @Mohammad. I don’t recall which ones, but several of Mohammad’s plugins are essential to my work (especially the biblio site), so the idea of assembling a version without those plugins, in order to troubleshoot an intermittent/whack-a-mole problem, was not looking good!

Actually, I found this thread where Mohammad seems to be indicating that all kookma plugins incorporate uglify…

IMPORTANT NOTICE
From Tiddlywiki 5.2.3, the packaged form of kookma plugins are distributed as minified tiddlers. The minification are done using Uglify from Flibbles.

I don’t really understand the difference between uglifying only some elements (within a plugin) and uglifying the whole wiki — which apparently was happening with my wikis (without my ever invoking such a process directly), given the discrepancy in some core shadow tiddlers, noticed by @buggyj above.

@Mohammad I'd like to request, please, that you find a way to release your plugins without uglify-ing the source. Debugging this issue has used up far too many person-hours. Thanks!

As @Mohammad pointed out, this isn’t actually the case any more.

The source for these plugins is available on GitHub. So we can repackage them relatively easily.

If you need help getting versions of these plugins without the uglification, please let me know. If you’re comfortable with the command line and don’t mind installing Node and Git, I can give you instructions. If not, I can do them for you. I’ve just done it for RefNotes. Of course, even better, as @CodaCoder says, would be if @Mohammad can offer both versions. But I haven’t seen much of him lately.

The version on Kookma is 43,031 bytes. When I packaged it as source it’s 60,284. So uglification reduced it by 30%, which is meaningful but perhaps not important enough to insist on it.

1 Like

Dear all,

Sorry for the late reply. I will update the plugins without Uglify, but if you kindly be patient for a few days to use the new planned TW 5.3.3.
The current structure of kookma plugin repos is:

  • Demo + minimized plugins using GitHub pages (it seems most users like to drag and drop plugins into their Wikis)
  • Source code (useful for who use TW on Node.JS)
  • Minimized packaged plugin (also works as drag and drop)

From TW 5.3.3 onward, I will publish demo+plugin without minifying.

Again, I appreciate your patience and sorry for not being more active on the forum.

3 Likes

The issue is with Uglify. There is a report of issue on GitHub by Mohammad.

For those use kookma plugin, they can install latest kookma plugins from CPL (Chinese Community Plugin Library) without minimizing (no Uglify)

2 Likes

Hi @CodaCoder
The source is not uglified! Only the packaged one (also distributed in demo page). Please see my recent reply in the thread.

1 Like

Reading through this thread, I’m wondering if it would be better to stop uglifying the external core js on Tiddlyhost.

The size differences are as follows:

 2349000 tiddlywikicore-5.3.3.js
 1355873 tiddlywikicore-5.3.3.min.js

 424214 tiddlywikicore-5.3.3.js.gz
 291541 tiddlywikicore-5.3.3.min.js.gz

I expect most browsers fetch the gzipped version and cache it, so the benefit is a roughly 30% smaller one-time download. Maybe that benefit isn’t worth the extra difficulty it brings with troubleshooting and debugging.

Are there any arguments in favor of keeping the uglification? If not I’ll probably remove it soon from the “external core” TiddlyWiki on Tiddlyhost.

1 Like

I think @saqimtiaz mentioned the he has some users with very limited data plans or really limited mobile connectivity. @saqimtiaz what do you think about the minified core?

Perhaps its not as importiant to minify a core that is externalised for all tiddlyhost site?

Thankfully there has been progress in the last few years and limited bandwidth is far less of a concern than it used to be for that group of users (in Central Asia). To my knowledge, none of them use TiddlyHost.

I think that it makes sense to not uglify the external core version.

As you wrote in your size-comparison – The savings for a 1 time download is about 100kByte if the server “gzipps” the code.

So it’s probably an advantage to go with a conservative approach an use the default core gzipped.

Just some thoughts.

1 Like

Hi Simon,

Uglify has been updated to 1.8 and TiddlyWiki updated to 5.3.3.
Now these two work great! So, I think you can keep the minified core on Tiddlyhost if you like.

I’m delighted that the current conflict is resolved by the combined updates!

Still, I think part of the motivation of @simon’s idea here was to maximize ease of troubleshooting if/when there is any kind of unexpected behavior. It’s sobering that even @jeremyruston was not able to grok the problem until I could rebuild an internal-core version that replicated the issue. In theory, any issue that requires inspecting the source code — even an issue that turns out to be unrelated to uglify — would be harder to troubleshoot if/when it affects projects that have been compressed this way.

Since uglify is not easily reversible, it seems wiser to me to have the tiddlyhost setup default to a non-uglified default for external-core wikis.

This compromise seems to hit the “sweet spot” of avoiding redundant server-side and bandwidth burdens — especially important for users like me who run multiple tiddlyhost projects, and who also store the backup history (grateful to @simon for making such things possible!) — while minimizing the risk of the code being virtually unparsable to human eyes when that’s what’s needed.

Surely, those who wish to use a compressed / uglified version of the already-lean external core can of course still do so, correct?

It would be fitting to conclude this thread with a shoutout to this suggestion. Tiddlyhost is an amazing tool for the community, and the fact that @simon has allowed for a free level is fantastic as a resource for beginners and those whose storage needs are modest.

The paid plan is very reasonably priced, and helps to keep the servers running while also enabling further features.

Hear! Hear!

This is one of the most useful tools imaginable!