Internal hyperlinks not working in the HTML export

Steps to reproduce

  1. Create a Dynalist node.

  2. Obtain the link of your Dynalist node (under “☰ → Get link …”).

  3. Insert this link into another Dynalist node in the same document, either as raw URL or as Markdown link. After leaving the edit mode of that node, it will be rendered in a special way with a little Dynalist icon in front.

  4. Export the document to HTML (under “☰ → Export … → Formatted → Download as file”).

Expected result

The hyperlink should be an internal hyperlink in the HTML document, because it was an internal hyperlink in the Dynalist document before.

This would allow to use these links as cross-references within the same document.

Actual result

The hyperlink is present, but just as entered in Dynalist with a URL of scheme{docid}#z={nodeid}. These links are not usable as internal cross-references in the document, as visiting them needs (1) Internet access, (2) access to the original document on Dynalist and also (3) it’s slower and uncomfortable than the instant jump to another location in the same document.

Unfortunately, the exported HTML document also does not contain the Dynalist node IDs so that correcting these links manually is not possible either.

Agreed this is a limitation right now. Not sure there’s much we can do without massively changing how exports behave. I also don’t think there’s an ideal behavior since this is a limitation of how we store data.

Mmh yes, if you want exports to verbatim contain the text as entered on Dynalist, converting the links to relative links on export would not fit into the system. Makes sense to not special-case just this one type of links on export.

I’d see this alternative: making relative links to other list items work inside Dynalist documents, such as [example link](#z=VCyTakohoNYEAw-). And then making them also work in HTML exports by adding id attributes to all <li> … </li> tags.

Users would have to remember to insert these relative links to create exportable cross-references, but that might be supported with a new “Get intra-doc shortlink” menu item in the context menu. (Shorter links are more beautiful in source view anyway :slightly_smiling_face:.)

In addition, the OPML export can also contain the link targets as <outline id="…" …/>. That’s valid OPML since the outline element “may contain any number of arbitrary attributes”. Links would not work out of the box this way, but it would allow to make them work with a custom script.

1 Like

Also see here for a similar problem when exporting to Markdown. Preserving links upon export is hugely critical — not because I or any one individual “wants” it, but because links are a fundamental way of organizing thoughts. Hierarchical outlining is one way; links provide a complementary approach. Together, it can be quite powerful. A reasonably simple solution is provided by @Alexander_Peczony over at this thread:

It’s a workaround but…If you need internal links to work in HTML, what I would do is Expand All and then from the browser itself click Save Page As… And then in a plain text editor strip out the http://dynalist… strings before the # so that only <a href="#… internal links remain. You will need to host this HTML file online since browser security won’t let you click file:// links. And you’ll need to add some Custom CSS or edit the HTML further if you don’t like the default look of Dynalist. But at least it will retain the linkable node strings like you want. In theory.

1 Like

Yeah my experience is that links always break in the end. So I use tags instead.

I’ve never had an internal link break

Just move a node that is linked to, to a New document. Voilla…

I just tested that, link did not break.

You’re talking about internal links where you type [[ and then some characters and click the one you want right? Then the node contains markdown like [bonk](

Those links seem robust, how would they break?

I was unclear. If you move a node that you link to to another document, then the link breaks. (I’m not saying it’s not understandable.) So when you archive a parent node to another document this could quickly happen in one of the child nodes without you being aware.

1 Like

Oh, I get it. Yeah. Sounds like a tricky bug. I know they have a “backlinks” functions, I wonder if they couldn’t use that to find>replace all the links pointing to the node when moved between documents. I assume someone reported this bug?

I’ll add this to my laundry list of reasons I have 1 document and 1 document only, for everything. There’s a poll where 60% of dynalist users only have 1 document, since so many functions don’t work well between documents.