^linkTo()^ problem

Hi community.

I’m running into a problem with ^linkTo()^.
To make things as easy as possible, I’ll say this:

In an HTML template I made, I have a table with a cell I would like to be linked:

When I’m in preview mode (the note’s export template is correct), the link is there, but it does not work when I click or choose “open link” from the context menu.

Any thoughts?

The first thing to do in such a context is to look at the note’s text pane ‘Export’ tab and to look at the HTML. Can you post what HTML code you see and, separately, what you expected to see?

Other considerations re use of ^linkTo( item [, data] [,css class] )^:

  • item must be a single item, it can’t be a list
  • as you’re using a note $Name for item, ensure it is unique. Generally $Path is a better choice. In all code—action or export—that want to use note(s), Tinderbox needs an unambiguous reference to the item(s). If faced with a choice, Tinderbox picks the first by outline order ($OutlineOrder). So if using $Name and there is an agent matching your note before the actual note in the outline, then the match is to the alias.
  • the link type string (argument #3) in links is a regex pattern so case sensitive.
  • it may be that a links() call can’t be evaluated (i.e. to return the named item) within the context of a `^value()^ code.

If the last above is the issue, use an `^action^ call to set a variable to hold the name and call the variable’s value in template code, something like:

var:string vItem = links.inbound."Includes".$Path;
)^<!doctype html>
<!-- ...template code -->
<!-- further down, use the var -->

See also: links[(scope)].[directionStr].[linkTypeRegex].attributeNameRefStr.

Thanks for the reply, @mwra.

It doesn’t work even with the ^action()^ you kindly suggested.

here is the HTML:

עותק של שיעור מתחילים בשינוי גישה הורית.txt (11.1 KB)

Thanks, so the problem code is:

<td><a href="../תיקיית מודולים/מודול הקדמה גישה חדשה להורות.html">מודול– הקדמה: גישה חדשה להורות</a></td>

But you don’t say what the correct path is.

I’m unfamiliar with Hebrew, but do note it is a right-to-left script and noticed the following discepency when looking at the file you sent. Here is the URL as shown in Safari’s Web Inspector view:

Now, the same viewed in BBEdit:

Notice how the Hebrew part of the path is transposed in one of these, though my lack of Hebrew knowledge means I can’t tell which is wrong.

The suspicion is some tools are rendering Only the Hebrew part of the mixed script string. Of the two, the BBEdit looks correct as the anchor text of the note is the same as the HTML file at the end of the target URL/path. In Safari the anchor text and target HTML file name differ.

So, though I can’t offer deeper insight, the mix of right-to-left and left-to-right scripts may be a factor. I see you do include a script direction attribute:

<!DOCTYPE html>
<html dir="rtl" lang="he">

Which seems appropriate. Beyond that, I’m afraid I can’t help further other than suggest you look at the code in text pane’s Export tab and check the path is as you’d expect.

This is backward Hebrew.

The code is getting the correct link and presenting it right:

Everything is ok. The link is even clickable. But it’s not taking me to the note of the link

That is less clear than you imagine. Because:

  • Does the target article exist?
  • If so, how does the path differ from the relative URL being generated by ^linkTo^
  • If different which path is ‘wrong’, given that we’d expect them to be the same.

The fact the link doesn’t work is no longer of help as we know the link is being correctly generated, but one or more of the following applies:

  • the above link is pointing to the wrong place. If so that suggests links() is matching the wrong note, in which case you have an action configuration error.
  • the target article is not exported, i.e. the link fails not because the URL is wrong but because the expected target is not there.
  • The target note is exporting, but to a different location or to a different name.

For the last 3 can you give me an answer as it will help indicate where we need to look next.

Given everything else that works, i.e. my hunch about it being left/right direction issue was wrong we need to look elsewhere. i’d suggest you also

  • manually generate the URL you think you should get and compare it to the code the template is creating. Are the two the same.
  • set a note’s $Text to the output of the links() and check it is supplying only one note and that the note is the one you are expecting, in the location you are expecting.

In other words you may likely be using the right code syntax but possibly inputting (unintentionally) either wrong or ambiguous (to Tinderbox) data with the result that a link is generated to the wrong target

It’s also worth checking that the reason the link doesn’t work might be that the target note isn’t being exported (easily done!) or exported to a different location to where Tinderbox thinks it should be.

Bear in mind ^linkTo()^ assumes the target not is exported using a fixed or app auto-generated filename and to a location consistent with the exported root of the document. For most people the root of the Tinderbox outline is the root folder of the export. Exported containers are named as per their HTML exported filename even if the folder doesn’t actually generate an actual HTML file: for instance the container itself has no $Text but it has exporting child notes.

I’ve had a similar problem in my document. The link was correct but didn’t lead me to the note. Only after I exported the Tinderbox document (in html) did the link work.
Maybe that wil help for you too?

Thanks, @mwra
Thanks, @jmesenig, it works! Just like you suggested. I didn’t change the link or the code.
@mwra, I can’t change the link because the mixed rtl ltr is messing everything up, even manually.
Thank you guys


One more thing:

If I delete the exported folders and files, it does not work

I know. Forgot to tell you that. I created a temp folder on my ssd in which I save the export. Every time I change the tinderbox document I have to make a new export.
Don’t know if this is normal behavior.

Yes. I get the same here. I don’t know if it’s normal or a bug. Thanks anyways @jmesenig

The solution suggests a missing part of the context—checking links in preview before exporting the whole site. This might need a little explanation.

Recent changes to allow configuration-less Preview had a side effect for previewing exporting content.

Now, by default, the Export Inspector’s Export To: uses a hidden temporary folder for Preview so that works seamlessly. In this mode any pages needed, e.g. the target of of links between notes are created as needed in the background (and tidied up after ) by Tinderbox.

But if the user sets an OS folder for Export To:, Tinderbox expects any linked-to note (exporting from the doc) to exist already. IOW, if checking inter-page links, export all pages first, before testing the links. Be aware that if the only change made when re-exporting is template code, you need to either delete the existing exported page or use File ▸ Export Selected Note lest the app think the note is unchanged and not needing a re-export.

In summary, it appears the mistake—albeit unintended—was to not export the whole site before attempting to check inter-pages links in preview. An alternative approach is to reset the document to use the internal Temporary Folder whilst testing and only then export the whole site. Even simpler, for those who can read HTML code—just look at the code in the Export sub-pane of the Text pane, so avoding the need for preview.

The ordering of the sub-panes is perhaps unfortunate as it is clear that many don’t bother to look at the generated (HTML) code , perusal of which would instantly show some errors and avoid endless to-and-fro to Preview whilst trying to guess the error which is plainly seen in the underlying code.

So the link was failing because the target page hadn’t been exported but the app had no way to know that. No critique here as all the above is more obvious after first encounter. Sorry for the long reply but I think it might help a few others who might be researching this issue.

[Note to self: I’ll see if I can’t find a more concise description of the above dilemma for aTbRef]

1 Like

Thanks, @mwra.

So now it works fine with no need to export first.

I set all the notes to a temporary folder in the export inspector and checked all the notes in the Export checkbox in the export inspector, and now when I’m in preview, without having to export the document, the links in the preview pane work fine.

But, whenever I update the template, I need to click “Use Temporary Folder” again to work.

Thanks for clarifying!

I now have reset the export location of all the pages by clicking the ‘Use Temporary Folder’ button

and can see that the files are created. But only when I preview them individually first. So in my case that would mean that I have to manually preview about 1.000 pages (?)
Am I doing something wrong here?

This may be same as for export. A note has no way to know if it’s template has had a change. Bear in mind that template may be set dynamically so a note doesn’t necessarily easily known which template it uses.

I think perhaps you misunderstood my previous explanation. If exporting content, as opposed to using preview only for internal preview, you need to export the whole document (or those parts indended to export) once before trying to use lin. For a non-internal use site, Tinderbox does not export linked-to pages as it assumes you have already exported the site at least once. when you follow an in-site weblink in preview, if the doc is set to export, the content read is the export of the target page. If the user has failed to export that target page, a following a link to it in Preview will show nothing because the target page doesn’t exist in the export site

If tempted to say, can Tinderbox ‘just’ make the page if needed, consider a note like the source of this web page, that has hundreds of links. Previewing that page in a doc set to export and if expecting export-on-demand, would result in Tinderbox having to export 00s of pages.

As well as link-to pages, in preview an exporting page looks to the h/d exports for images, CSS, JS files, etc. Using preview to link-check exporting pages seems a sub par use. Better to export the page and check the links there.

If this seems messy it is because ‘Preview’ got pressed into the service of two similar looking but different purposes:

  • Previewing the look of exportable notes. Originally you just got the (HTML) code and had to open the exported page to do a visual check of the page.
  • In-app presentation mode (no export). A sub-set of users want to view their notes in an HTML-rendered form, either for aesthetics or because they only understood writing in Markdown (which needs to be rendered to ‘see’ the Markdown).

Perhaps the two should have had different interfaces, as people now try to use Preview as a web browser and that is not really its function.

Looping back to the start. If checking links on exporting pages, it is better to export the pages and check in a web browser.

Don’t shoot the messenger here - I’m just explaining how it works. This is one of those parts where different sub-groups of users wanted a different behaviour from the same feature. inevitably this leaves a few difficult edge cases.

I’d repeat the mantra though: if preview isn’t working look at the HTML in the Export pane. Preview tells to it looks wrong, or can’t find the target note: but it doesn’t tell you why. For that answer you need to look add the exported code, by looking at the Export pane.

If you preview an exporting note and a link fails, check the link code in the Export pane. Does it point to the right (relative) URL? If so, is the target note actually present at that export location? In this case, doing the latter would have showed the link was correct (so no template code error) but the user had failed to generate the target note thus no page found on following the link (so user error, albeit unintentional).

I sense a meet-up ought to perhaps explicitly cover this—in terms of the disconnect between users initial assumptions and how the feature actually works. IOW, show these failure live and then explain why they occurred. seeing the process work tends to skip past people’s miss-assumptions as to how the process works.

@mwra Thank you for you extensive explanation. It’s clear to me now that previewing is not the same as viewing the document in a webbrowser.

Certainly not. My bad, I just misunderstood the functionality.

I think that is the best solution for me because I need to export the document anyway for publication purposes.

Again many thanks for your help.

1 Like