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:
<td>^linkTo(^value(links.inbound.Includes.$Name)^)^</td>.
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] )^:
links is a regex pattern so case sensitive.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:
^action(
var:string vItem = links.inbound."Includes".$Path;
)^<!doctype html>
<!-- ...template code -->
<!-- further down, use the var -->
<td>^linkTo(^value(vItem)^)^</td>
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:
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:
^linkTo^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:
links() is matching the wrong note, in which case you have an action configuration error.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
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.
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]
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:
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.
