Adding any “reference links” or “filters” through the browser address bar in the tiddlywiki URL suffix (local and online) is prohibited. In fact, tiddlywiki allows this by default
Or when manually inputting them, tiddlywiki no longer parses them, or switches to gettingstart tiddler
for example
#%24%3A%2FControlPanel
#:[tag[233]]
Any response would be greatly appreciated
I’m sorry, but I do not understand what you’re asking. Or if you’re commenting on something instead of asking a question. Could you rephrase?
An URI consists of different elements. A scheme, authority, path, query and fragment as shown in the image below.
You refer to the fragment identifier, which is defined by the spec as:
“The fragment identifier component of a URI allows indirect identification of a secondary resource by reference to a primary resource and additional identifying information.”
Our primary resource is tiddlywiki.com and the secondary resource are our tiddlers. So we can use the URI-fragment to directly access specific tiddlers within a wiki. For a single tiddler we call this mechanism Permalink. For a set of tiddlers we call it Permaview. That’s perfectly fine. Nothing is prohibited.
Further down in the spec it says:
As with any URI, use of a fragment identifier component does not
imply that a retrieval action will take place. A URI with a fragment
identifier may be used to refer to the secondary resource without any
implication that the primary resource is accessible or will ever be
accessed.
This means, that if you manually change the fragment identifier and hit enter - nothing happens, since the browser does not trigger any action, that the app could listen to.
So if you manually change the fragment you have to reload the page. That’s the only way to “parse” the fragment. … as defined in the spec.
TW does not support the “query” string atm.
hope that helps
-mario
TW has a setting in the ControlPanel → Settings section which has 3 options:
A second setting:
Update browser history when navigating to a tiddler:
If 1) is selected the browser history will be updated with every action in the wiki. That means you can use the native browser Back and Forward buttons to navigate the wiki
Choose how permalink/permaview is handled:
[x] Copy permalink/permaview URL to clipboard
[x] Update address bar with permalink/permaview URL
At tiddlywiki.com both options are selectged by default. If you unselect option 2 the URL will not be updated anymore if you create a permalink or permaview
And to be clear you can put a search filter in the address bar. It is not prohibited.
for example https://tiddlywiki.com/#:[tag[Examples]] however you may7 need to use a href to delimit the link <a href="https://tiddlywiki.com/#:[tag[Examples]]">go</a> go
Hi @XYZ none of the options that we currently provide prevents TiddlyWiki from responding to changes made in the browser address bar.
I think one way that it could be done would be to define a custom layout which uses a navigator widget tied to custom $:/MyHistoryList and $:/MyStoryList. The core would still be changing $:/StoryList and $:/HistoryList in response to address bar changes, which would not affect what is being displayed.
I would be happy to consider a hidden setting for disabling the response to changes to the browser address bar.
I hope the suffix added after the URLs *.html and */ will make tiddlywiki unresponsive both offline and online, instead of triggering actions
Is there a solution to prohibit access to URI tagging
Can it be disabled through style settings
That’s right, I’m very interested in hiding tiddlywiki and making corresponding changes to URLs
