How to delete a tiddler without opening it?

365 views
Skip to first unread message

Ed

unread,
Feb 8, 2016, 7:39:16 PM2/8/16
to TiddlyWiki
Dear All,

Got a tiddler playing havoc with one of my TW 5.1.11
I have made a link in a tiddler to a website, That worked fine.
I added some text and linked another website

Putain, what happens now!

My TW disappeared all of sudden from my browser
and the last website I was linking to appeared.

Now I can not open that tiddler because very rapid
the linked website appears and I can not click on
the edit icon.

This happens every time I try to open that diddler
Aaarggghh.

Of cours the tiddler appears in the menu under Recent,
butI can not delete it from there, anyway I can not.

What can I do to destroy that tiddler without destroying
the whole TW.

Thanks in advance for any help.
Salut! Ed


Scott Simmons (Secret-HQ)

unread,
Feb 8, 2016, 10:32:32 PM2/8/16
to TiddlyWiki
Hi, Ed —

If all else fails, you can open your TiddlyWiki file in a text editor (Notepad, WordPad, or TextEdit) and edit the HTML directly.

Before you do, be sure to make a backup of the file, just in case you delete more (or less) than you intend to on the first pass.

Individual tiddlers look something like this:

<div created="20151003090151608" creator="YOU" list="[[next up]]" modified="20160125204909939" modifier="YOU" tags="YOUR-TAGS" title="TITLE OF THIS TIDDLER">
<pre>YOU'LL FIND THE BODY OF YOUR TIDDLER HERE</pre>
</div>

Delete from <div down to </div>, save the file, and reload your TiddlyWiki.  That should get rid of the offending tiddler.

Jed Carty

unread,
Feb 9, 2016, 1:40:30 AM2/9/16
to TiddlyWiki
You can make a new tiddler and put this in the body:

<$edit-text tiddler='the probelm tiddlers name' class='tc-edit-texteditor'/>

and then take out the text causing the problem so you can open the tiddler and delete it normally.

Odder

unread,
Feb 9, 2016, 1:48:57 AM2/9/16
to TiddlyWiki
Or you download an empty TW and import your Wiki except the certain tiddler which makes the problems.

Odder

Ed

unread,
Feb 9, 2016, 6:26:56 PM2/9/16
to tiddl...@googlegroups.com
Hi Guys,

Lotsa thanks for the support! All of you. Three methods even.

Well I opted for the lazy one, by Odder. I upgraded, as I always have
several tiddlers from the full TW also on board, for reference. 't Was a cinch!

BTW, I tried out iFraming the website again that apparently caused this trouble
Grin, on an fresh downloaded TW 5.1.11 of course.
Did the same thing.
First I iFramed the website that didn't create havoc and then the other one.
Bingo!

May I suppose that the offending website has a sort of mechanism that prevents
"deep linking", if that is the correct term?

Thanks again & Cheers! Edm.
@Jed: Ça va? Tout va bien? Toujours à Paris? 8-))
====================================


Op dinsdag 9 februari 2016 07:48:57 UTC+1 schreef Odder:

Eric Shulman

unread,
Feb 9, 2016, 8:20:25 PM2/9/16
to TiddlyWiki
On Tuesday, February 9, 2016 at 3:26:56 PM UTC-8, Ed wrote:
May I suppose that the offending website has a sort of mechanism that prevents
"deep linking", if that is the correct term?

It's a common technique for sites that don't want to be iframed:

Basically, it's code on the remote site that detects when it is being displayed in an iframe, and then "busts out", taking over the whole page.

-e

Eric Shulman

unread,
Feb 9, 2016, 8:28:10 PM2/9/16
to TiddlyWiki
addendum:

According to the link I posted:

The iframe in HTML5 has a sandbox attribute. The attribute's value is a set of allowed capabilities for the iframe's content. If the value is empty or not set, the iframe's content will not execute JavaScript, and won't allow top-level navigation. By specifying allow-scripts in the space separated set of exceptions in the value, the iframe will allow JavaScript, but will still disallow top-level navigation, rendering framekillers in the iframe impotent.

Based on the above, you might want to try:
<iframe sandbox="allow-scripts" ...>

One thing that isn't clear to me.... if your browser supports the HTML5 standard, then it should have blocked top-level navigation as well as scripts, by *default*. But perhaps they have it turned off for compatibility with current iframe usage on many sites, which expect scripts to work.  Still, worth experimenting...

enjoy,
-e

Scott Simmons (Secret-HQ)

unread,
Feb 9, 2016, 10:02:18 PM2/9/16
to tiddl...@googlegroups.com
Wow.  That works, Eric!

Though I don't quite understand the how of it.

"If the value is empty or not set, the iframe's content will not execute JavaScript and won't allow top-level navigation."

By that reasoning shouldn't framebusters generally be kinda impotent?  I don't think many developers declare the sandbox attribute, but I still see plenty of framebusters doing their job.

Maybe the Wikipedia page just needs an edit for clarity.  ;)  (Or maybe there's a word of phrase in there I'm glossing over, which is always possible.)

In TiddlyWiki's case, I'd have expected the "You have unsaved changes. Are you sure you want to leave/reload this page?" popup dialogue to stand between the iframed page and its takeover of the browser tab.  (If that's the case, Ed, you may have yet another trick to deal with this in the future:  Edit a tiddler without saving, then open the problematic tiddler, dismiss the dialogue box, and edit the problematic tiddler.)
Reply all
Reply to author
Forward
0 new messages