Closed dongrentianyu closed 1 year ago
As a workaround you can open the tiddler and set the field code-body
to yes
. .. It will be shown as plain text, but still works as intended.
The loss would be that we wouldn't be able to see this entry displayed. So the further question is how to display it only once and not get stuck in a dead loop
If you change something in the story template and save it, you'll see it immediately once you save it. So the preview IMO is not needed anyway.
I usually open UI template tiddlers to see the code and not to see a preview.
As a workaround you can open the tiddler and set the field
code-body
toyes
. .. It will be shown as plain text, but still works as intended.
The solution is indeed this, but this is only because this entry is relatively small. If this entry had a lot of content, it would be stuck in an unclickable state. See the forum discussion at .
@Jermolene -- It seems the recursion-protection fails with v5.3.0. With v5.2.7 the protection "kicks in"
Hi @dongrentianyu @pmario the recursion protection is working as intended here: a fixed number of recursive transclusions are allowed, but once they reach that number further transclusions are disabled. Prior to v5.3.0 a different recursion detection mechanism was used, that worked by preventing repeated nested transclusions with the same parameters. The advantage of the old approach was that it would cut off recursions like the OP immediately. The trouble was that the old mechanism couldn't detect many types of infinite recursion. The new mechanism just relies of detecting excessive stack growth, and is robust.
It is possible that we should reduce the maximum allowed depth, which is currently set to 1000:
In any event, I think the OP here is really about the failings of the current view template body cascade filter for the code body view. The filter is currently:
Broken up to be more readable:
[prefix[$:/boot/]]
[prefix[$:/config/]]
[prefix[$:/core/macros]]
[prefix[$:/core/save/]]
[prefix[$:/core/templates/]]
[prefix[$:/core/ui/]split[/]count[]compare:number:eq[4]]
[prefix[$:/info/]]
[prefix[$:/language/]]
[prefix[$:/languages/]]
[prefix[$:/snippets/]]
[prefix[$:/state/]]
[prefix[$:/status/]]
[prefix[$:/info/]]
[prefix[$:/temp/]]
+[!is[image]limit[1]then[$:/core/ui/ViewTemplate/body/code]]
The trouble is the run [prefix[$:/core/ui/]split[/]count[]compare:number:eq[4]]
. It is intended to distinguish between templates like $:/core/ui/EditTemplate
that should be viewed as code, and UI components such as $:/core/ui/ControlPanel/Stylesheets
that should be viewed as wikitext.
Perhaps the best fix would be to switch from using the cascade to using an explicit code-body
field for a bunch of the core templates:
$:/core/macros/*
$:/core/save/*
$:/core/templates/*
$:/core/ui/*
It looks like there is a protection mechanism in place, I was overly concerned.
There are 280 tiddlers that match the filter: [all[shadows+tiddlers]prefix[$:/core/ui/]]
I did create a button that can open all of them.
Important: This button will brick your wiki, without the new cascade tag-filters and code-body
settings mentioned below
\procedure openAll()
<$list filter="[all[shadows+tiddlers]prefix[$:/core/ui/]]">
<$action-navigate $to=<<currentTiddler>>/>
</$list>
\end
<$button actions=<<openAll>> >
Open all tiddlers `prefix[$:/core/ui/]`
</$button>
There are 10 of them which need a code-body: yes
, because they can cause "catastrophic rendering" distortions.
The rest of them can be covered with tag filters
core-ui-tags: [tag[$:/tags/PageTemplate]]
[tag[$:/tags/EditTemplate]]
[tag[$:/tags/ViewTemplate]]
[tag[$:/tags/KeyboardShortcut]]
[tag[$:/tags/ImportPreview]]
[tag[$:/tags/EditPreview]]
[tag[$:/tags/EditorToolbar]]
[tag[$:/tags/Actions]] :then[[$:/core/ui/ViewTemplate/body/code]]
With those settings applied, the button will work fine and IMO the "view state" works as intended.
PR will follow soon.
Closed in #7583
Describe the bug
When you enter this entry, it gets stuck in a dead loop, but the page still loads out without getting completely stuck and unclickable.
Would it be considered to add a code-body field and set the value to yes to prevent this error from occurring.
The loss would be that we wouldn't be able to see this entry displayed. So the further question is how to display it only once and not get stuck in a dead loop.
Expected behavior
No response
To Reproduce
No response
Screenshots
TiddlyWiki Configuration
Additional context
No response