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

#15

Yes, I no longer have that symptom after reloading, I see its 5.3.2 Now.

I will have a look around Biblio-Springer.

  • It also breaks my focus tiddler solution

One thing I have observed is on tiddlywiki.com if you click a title, it navigates to it, but the ctrl-click only opens it below, this is the behaviour of your wiki. That is navigation is behaving like $scroll=no

  • I cant download and disable plugins (because of the external core?) but its a good bet that $:/plugins/wikilabs/edit-tabs could be involved because it overrides $:/core/macros/tabs includes;
\define link-action()↩︎
<$action-sendmessage $message="$(message)$" $param=<<currentTiddler>> navigateTo=<<currentTiddler>>/>↩︎
\end↩︎`

  • But some hacking did not prove this.

  • I also notice $:/LinkStyle/Stylesheet mentions links, but removing all your custom stylesheets by tag nothin changed.

  • Linkcatcher is in the commander plugin

For now that has exhausted my ideas, a bit of a mystery.

#16

In my very last set of system-tiddler re-imports (in the process of replicating this biblio project on an empty v5.3.2), the culprit seems to have been added.

This was the list of tiddlers that seems to be doing the mischief:

The following tiddlers were imported. (The first one, $:/clear is just a shorthand tiddler for clearing all floats, using system prefix just to reduce visual noise in sidebars.)

image
image1456×582 108 KB

#17

I just went through every tiddler in that fateful last import, and deleted each of them, one by one — so the list is now 100% italics (tiddler missing) or bold (restored to shadow state). Saved, reloaded, after each deletion. Still no scrolling for internal links.

Problem is still afoot. Alas, must get to bed!

#18

I can’t offer any help… just to say, I’ve seen this behavior twice in the last week or so. Yesterday it was happening, I closed the wiki, reopened, problem was still there. Messed around with “Open links above” and “below” – nothing worked, went to bed, came in this morning and everything is working.

When a tiddler is open in the river, links in the Open tab do nothing. The closing tiddler animation doesn’t happen either.

Links clicked in tiddlers DO open the target into the river, but the river refuses to scroll to them.

Now, it’s all working fine and apart from my tinkering in the control panel and having given up trying to make it work, I can’t explain why it’s now working or why it stopped working in the first place.

I checked biblio project and can confirm that’s the same behavior I saw yesterday.

(Random thought) You don’t seem to be using eventcatcher (I looked). You are using linkcatcher (kookma’s commander). Anything that interrupts link/click handling might be suspect.

@Jermolene Checking the biblio site I see nothing in the console beyond a ton of CSS warnings/errors

1 Like
#19

I am on the night shift, and like a good challenge. I know two things I do not have answers for that may be related;

  • Info > Advanced > Parsing > wikilink is disabled :face_with_raised_eyebrow:
  • Sidebar tabs open/recent some tiddlers have icons, do not have a caption or icon field
    • somehow the link widget must be change for this?
    • These are bibtext tiddlers

I thought I would try something and navigation is now working for me

  • I downloaded empty.html
  • Downloaded the Biblio-Springer using a download button download-wiki-with-changes.json (1.7 KB)
    • Of note the BibText Importer was disabled at the time (may not be relavant)
  • Downloaded the tiddlywiki core to the same location
  • Opened empty html and imported everything (after I reviewed it) from the local Biblio-Springer (until I added the core this failed)
    • Except I unchecked $:/plugins/tiddlywiki/bibtex (may not be relevant)
  • Save and reload, and the navigation is working

I then installed the Bibtext Importer and the wikis navigation is still working. (may not be relevant)

I have no explanation for this. But one question;

  • Has tiddlyhost being updated with the 5.3.2 External core? @simon
#20

I dragged $:/core/ui/SideBar/Open from tiddlywiki.com on to https://biblio-springer.tiddlyhost.com/ - imported it then compared - they are different -

#21

Not that I want this trouble to be widespread, but I do feel a bit more sane to learn that someone else has seen this behavior recently.

This is helpful, thanks. The commander plugin and edit-tabs plugin each caused no trouble on import (+save +reload), but perhaps there’s some additional factor in my wiki that plays badly with these in v5.3.2…

#22

This is indeed odd. Especially since links do seem to be rendering fine visually, and turning this parsing rule off should prevent such rendering, no?

This is the linkstyle solution I use on all my projects. It’s just css, should not affect any activity.

This is a good question to pursue…

However, this version of the wiki is NOT external-core, and has the same problem: https://just-for-troubleshooting.tiddlyhost.com/ …

#23

UPDATE: Now I’ve got two contrasting versions of the site uploaded to tiddlyhost, both internal-core. (So, perhaps easier to troubleshoot. And good to rule out external-core as the cause.)

SUCCESSFUL rebuild of the site starting from empty.html — behaving well at my minimalist-test-mode address.

FAILED rebuild version (with “failure-to-scroll-to-link” syndrome): https://just-for-troubleshooting.tiddlyhost.com/ …

One has the problem, one does not. I need to turn to other tasks, but if anyone is clever enough to find a smoking-gun difference between these two, that might be the next step.

Given the experience @CodaCoder had, we might be looking at some brittle detail that’s hard to replicate.

#24

Since v5.3.0 the default setting to wikilink CamelCase links in empty.html was set to “disabled”, since the community requested it.

There is nothing strange about this one. See: https://tiddlywiki.com/#Release%205.3.0

#25

Thanks. I had indeed initially thought this parsing setting was about CamelCase links (which I’ve disabled for years), but then convinced myself otherwise by reading this documentation about wikilinks — plus trusting that @TW_Tones was probably right to be surprised by that detail.

1 Like
#26

So, to be clear, I now have two contrasting versions, including one internal-core version that shows the symptoms: https://just-for-troubleshooting.tiddlyhost.com/

I’ve also proven to myself that I can rebuild the site from empty.html and not have the problem. But I have NOT been able to isolate the difference between the bad version and this good one: https://minimalist-test-mode.tiddlyhost.com/

I realize the uglification still makes it hard to troubleshoot. I’m not sure exactly which plugins trigger the uglify, though.

And, do I recall correctly that once uglify has been activated, disabling those plugins doesn’t actually un-uglify? (If so, just disabling those plugins won’t make it easier to troubleshoot, correct?)

I could try to put time into attempting to replicate the link-scroll problem without importing those uglifying plugins. (But if RefNotes is among the plugins with uglify, then we’re talking about removing plugins that are essential to the nature of the site…)

Problems with tw5-uglify and TiddlyWiki 5.3.0
#27

In my case, it’s true I modified .../SideBar/Open – I often do:

image
image1102×307 19.3 KB

My wiki is now working, so it’s not that :confused:

#28

I create a new external core wiki on tiddlyhost and dragged $:/core/ui/SideBar/Open from tiddlywiki.com on to https://testincludecore.tiddlyhost.com/ - imported it then compared - they are different -

image
image786×696 75.5 KB

#29

Thanks. But while @Springer mentioned she does like to run with external core, I don’t do that. Red-herring?

Be interesting to see what @jeremyruston/@pmario think.

1 Like
#30

Interesting mystery.

Perhaps now is time to attempt to intentionally add back the functionality that is missing and perhaps that will shed light on the problem eg navigate message or event catcher.

  • I have one from before.

Just a note: the problem when its occuring effects more than open links, recent and others.

#31

A little bit of context, because I think it’s important.

  • Jeremy did a prototype late 2018, which was part of v5.1.18
  • GH user cdruan did extend the whole thing to make it more accessible in March 2021 - It was released with v5.2.0
    • There is a very detailed thread at GH, which shows how the project evolved.
    • There was a discussion to make external-core relatively prominent in the “Right sidebar → Tools tab”
    • It was decided that it should not be so prominent.
  • v5.2.7 got an update to download a single-file-snapshot from an external-core wiki.
    • The other way around is not encouraged.

------ end context

I do highly appreciate the external-core function for advanced users.

  1. I think it’s a perfect match for wikis served from GitHub pages, because it allows us to save back to the web, without a 2MB core overhead. So smaller wikis can be saved fast. Since the core can be cached by the browser only the wiki has to be downloaded if it changed.

  2. I think the same thing is true for tiddlyhost. TiddlyHost is free to use – but somebody has to pay for the transfer volume. IMO that’s the reason, why it makes sense that TiddlyHost wikis also use this version.
    I think everyone who extensively uses tiddlyhost, should consider to sign up for a “Standard Plan”

  3. Locally, I do use it with my local WebDav IIS server for several years now. For me it’s reliable and fast, with basically no system overhead. – But – I do have to say, that I need to use my webdav-lm plugin to counter etag-problems.

  4. I do not use uglified js or UI, because I need the readability for hacking and debugging.

I do have several single file wikis. Most of them are less than 10MByte, which is not really much if compared to modern phone JPG images.

A 12 megapixel image has from 1.5 up to 4MByte per image and most users have 1000+ of them on their phone and happily share them with WhatsApp. I know that they are downscaled, but still.

I personally do not care if I have a 100 - 10MByte wikis. It just does not matter – for my usecases.

Hope that makes sense
-Mario

1 Like
#32

Because of thread-and-reply order, you may not have seen where I confirmed above that I actually have successfully added back all the functionality in one internal-core version, without getting the problem.

Yet I have another virtually identical instance (also based on standard internal-core) that does have the buggy symptoms. As far as I can tell they are identical in function, though I did not follow the same sequence in adding things back in, and there is a small difference in shadow / overridden-shadow count that I still need to troubleshoot.

If this were a one-off incident, I’d say I’m “home free” because I’ve got one functioning version of my site. But at this point the glitch has started independently several times, so I’d really like to solve the mystery of what triggers it before it derails me again. :grimacing:

#33

I did read that, and had done so myself earlier.

But

Like you I still would like to get to the bottom of it, and what is odd is,

We would think we could find it in your original problem wiki.

#34

I’ve been thinking about this…

  1. While it’s true that I’m continually updating this particular wiki – i.e. there are changes being made – with regard to the opening/closing/scrolling behavior (lack, thereof), my additions aren’t going anywhere near that stuff

  2. I’m asking myself what else has changed?

Answer: the story river. All the time.

And of course, that includes changing the history AND the Open tab in the sidebar.

Clue?

3191d457

1 Like