Publish from Tinderbox to DEVONthink

Hi Adam, I’m glad you find the tools useful. I’ll take a stab at it this weekend, assuming 2020 doesn’t throw yet another crazy thing in the mean time (knock on wood).

1 Like

Pat, this is great stuff, even if it bristles right up against the rockier edges of Tinderbox when adding this to existing documents.

I’ve been trying to butcher these scripts to export Markdown (or even plain text, which is the same!) to DEVONthink, to not much success - even in terms of getting text out, let alone rewriting internal text links.

I went down the path of least resistance (and possibly least experience) and changed the scripts to create a “markdown” file in DTP, which is working fine - however, I hacked the HTML templates to generate something that looks more like markdown, but the documents always end up empty.

What could I possibly be missing, or getting wrong? I’m blindly assuming a ‘#’ is a legitimate character in a template and doesn’t need escaping. Is there some complex transformation process the scripts perform (and there is what looks like voodoo in there) that I didn’t realise? And how do I take advantage of that DEBUG flag (and what would it do?)

Are these DEVONthink or Tinderbox templates? If the latter, could you post some code. When ouptutting files, pay attention to the extension type as that tells other apps using the file how to handle it. IOW if you send MD code in an ‘.html’ rather then a ‘.md’ file it might confuse the next app in the chain.

In exporting from Tinderbox, do remember that ‘Export’, in the general templated manner is predicated on using HTML unless the user makes changes. Problematic in this is `^text^ exports HTML-processed $Text whereas ^value($Text)^ exports un-HTM-evaluated plain text but also without any inline indication of text links within $Text.

The first step in fixing your issue is to find where/how the process is breaking. I suspect it is unintentional mis-encoding or extensions that are at play rather then something more serious.

Hey Thanks for the response, Mark!

I have placed my templates in ‘/Document Management/Templates’ (rather than a top-level ‘Templates’ path as in Pat’s example).

In there, I have ‘HTML page’ (an instance of the HTML prototype) which has the following text:

Author: Dave Mee
Note: <!--   ** Standard Tinderbox Template [section page] **  -->

# ^title^

^text^

^children(/Document Management/Templates/HTML page/HTML item)

Inside that (ie, /Document Management/Templates/HTML page/) is a single note, ‘HTML item’, again with a prototype of HTML, which has the following text:

## ^title^

^text^

^children(/Document Management/Templates/HTML page/HTML item)

In /Document Management/Templates/ are two further notes, Links list (a HTML instance) containing:


^text^

^childLinks^

and HTML text (a HTML instance) containing:

^text^

I’ve triple-checked paths are correct everywhere, which I’m very confident of, at least: the system does create a note in DEVONthink, with the correct name, and links bidirectionally between DEVONthink and Tinderbox - but there’s no content in there.

I thought there may be a simple way to butcher the templates to generate plain text instead of Markdown without really telling Tinderbox that’s what it was playing at - but there’s another world of boutique syntax deadlines preclude me from fully exploring!

Whilst it is now recommended to use the ‘standard’ `/Templates’ root container for template notes, if created elsewhere in the doc they show up as available. Still, you can check they actually work by making a small test file specifically to test that possible case.

Though slightly different to action code practice, I generally quote-enclose template paths as well as just template names when a template is provided as an argument, i.e.:

^children("/Document Management/Templates/HTML page/HTML item")^

To where do these templates output (sorry, I’ve not go time to build out a whole workflow here). I assum you are expecting a ‘.md’ file. Are you getting no file? A file with no contents? If you invoke single-file export (File → Export selected note) is the result any different?

Put another way, what output are you expecting, where vs. what/where actually occurs?

I hadn’t considered using the menu item ‘export note’, which does in fact export a note with the correct name, but the contents ‘unable to find this template’ - this feels like the start of a clue!

I’m poking through wrapping paths in quotes and seeing where it takes me. If I can get a proper export working, then I suspect the rest will fall into place, even if that place is directly on my feet.

This sounds a familiar scenario. I should note that if a template is only used to render a note content in a manner that is included in some other note (e.g. parent including only the link counts of each child note as set va the chid’s template) them make sure you’re exporting the containing note, within which use of the desired template will then show (or not).

BTW, selected note export will default to the note’s ‘normal’ location within the whole doc export but only if the doc has been fully exported once (this is how I do quick corrections for typos etc in aTbRef single pages). Otherwise you can export the file anywhere. I note this fact as if your note uses CSS, JS etc and is linked via a relative reference those links may not find their targets if not at the correct relative location.

Still, selected note export is a real boon.

Also, don’t overlook the Preview tab of the text pane.

Thanks for all your (on-target) suggestions, Mark!

I created a new note and poked around in the Attribute Inspector, finding an errant HTMLExportTemplate set to a path not beginning with my non-standard ‘/Document Management/Templates’ path. Changing that has granted me a successful HTML export. I think I’m getting there!

(oddly, I don’t have the strip above the editor with the text/preview/html toggles showing)

1 Like

See the Window menu Show/Hide Text Pane Selector to toggle the Text/Preview/HTML selector buttons on off.

The are hidden by default as if you don’t export, likely you my never need the Preview/HTML tabs.

Once set for a Doc, it remembers the toggle state and uses it for all text pane use (but not in stand-alone text windows)

Hey Adam, I’m guessing that you are using a pretty old version of this tool - one that uses $MyString to hold on to some intermediate data. The most recent version of this file no longer does that - so I think you should have no problem using them together. I will try to update the Marked exporter so it also uses custom attribute names instead of $MyString. But in the mean time, please give it a shot using the latest file, and let me know how it goes.

I just uploaded a newer version that has a “Doctor” helper to check if your document has everything it needs to run, and provides steps on how to set up the document. It should be helpful in upgrading from an older version of this tool, to the newer one. You’d need to delete the old Actions (or it might be named Stamps) container, as well as the Applescripts container. Then you can follow Doctor instructions as shown in the video below:

4 Likes

Hi Pat,

Big fan, I have been using your script since you first posted and shared it. Many, many thanks.

1 question: Is it possible to export to markdown instead of html? If so, would it be possible to explain the steps.

Thanks in advance,
Tom

Thank you for creating such easy to follow tutorial. I’m sure it will help a lot of TB and DT users. When I create the new TB document and follow these instructions, it works fine. However, when I do the same with the existing database, where the view in marked2 is implemented (Preview your Markdown notes using Marked), the links inside the notes stop working in Devonthink.

1 Like

Hi Everyone,

I’m experiencing a strange issue with Pat’s base file version 0.5.1.

I have recently purchased Tinderbox and I’m using 8.8.
I have also DevonThink Pro 3.5.2 and MacOS 10.14.6.

I followed the workflow as:

  1. Download the latest published version of the TBX file from GitHub (so by downloading the file from the tags in the GitHub page)
  2. Unzip it and open it in Tinderbox
  3. Run the stamp “Run note action” and ensure that all the steps are checked in the doctor section
  4. Create two notes at the root level of the document (Note A and Note B) and link them together using the Ziplink
  5. Run the stamp"Publish All to DevonThink"

What is strange is that while Tinderbox was in trial version, the aforementioned workflow was working as expected and I would get the notes created in DevonThink with the expected links and so on…

Now that I have activated Tinderbox, when running the stamps “Publish Note to DevonThink” or “Publish All to DevonThink”, either Tinderbox crashes instantly or nothing happen (see below for more explanation).

When I say “nothing happens”, I mean that after running the action, the icon left of “SourceURL” attribute of the selected note will blink and then nothing: no note is created in DevonThink nor no link is sent back to Tinderbox.

I tried the following with no luck:

  1. Restart the Mac
  2. Clear the caches
  3. Completely uninstall Tinderbox and re-install again fresh
  4. Un-register Tinderbox (so going back to the trial version)

I then tried to dig in what could cause the issue when “nothing happens” happens.

If I remove the “^value($DTExportSource)^” from the AppleScript “Create DEVONthink record”, then the notes get created, but obviously empty.

In the same Applescript, I replace:

  • source:"^value($DTExportSource)^"
    by
  • source:"^value($Name)^"

And it output a note with the note name as the body content.

Do you have any idea how to solve or try to debug this issue?

Thanks.

Attached my example file:
publish-tinderbox-to-devonthink.tbx (210.5 KB)

If you have a crash log, send the file and the crash log to Eastgate. The forum isn’t set up to diagnose crashes.

There is a defect in the code in the note “Update DEVONthink record”. The second line – beginning “set theRecord...” fails in Script Debugger with “expected end of line but found identifier” error. Could be the cause of the crash, or cause of the failure. I suggest starting over with the correct text for that snippet.

on run argv
  tell application id "DNtp"
    set theRecord to get record with uuid  "^value($SourceURL.replace("x-devonthink-item://", ""))^"
    set name of theRecord to "^value($Name.replace('\"', '\\~~TB_DOUBLE_QUOTE~~\"').replace('~~TB_DOUBLE_QUOTE~~', ''))^"
    set URL of theRecord to "^include(this, /Templates/TB Return URL)^"
    set tags of theRecord to "^value($Tags)^"
    set source of theRecord to "^value($DTExportSource)^"
  end tell
end run```

Thanks for your answer. I have sent an email to the support team with crash logs included.

It turns out that an error in the improved .replace operator in Tinderbox 8.8.1 can break this document if the exported note contains text links, especially if the text links are near the end of the document.

I think we have a fix, which should be backstage in an hour or so. Meanwhile, it’s really time for breakfast!

3 Likes

I too am having difficulties getting this to work even in its own document using its latest version on github 5.1.

Just curious if others are having similar issues. I agree with Paul, there appears to be a basic defect in the code as he points out.

If you’re going to work with this script, please use the b482 backstage release or later.

b482 did not work for me. Curious if anyone else has gotten it to work with their documents.
Tom

Perhaps consider using an earlier version if you don’t need the newest features? It sounds like there may have been a recent-ish update that broke some behavior that this relies on.

I am running Tinderbox Version 8.7.1 (b467) and it’s working here. I’d be curious to know from others if this is an issue of it working on my machine, or of it working on that particular version.

If you’re just copying the code from that note and pasting it into Script Editor, there’s no chance it will work. It’s not AppleScript - it’s a template that’s used to produce AppleScript that is then piped to /usr/bin/osascript.