Feature Request: Add template blocks for GUID and Note Link

[bumper314]

Each Evernote has a GUID (e.g. 9b3692d0-af0b-4bc9-a57f-02f49b3692d0) which is also used to construct the internal Note Link (e.g. evernote:///view/810537294/s331/9b3692d0-af0b-4bc9-a57f-02f49b3692d0/9b3692d0-af0b-4bc9-a57f-02f49b3692d0/). I would like access to both of these values as Template blocks.

I know this is tricky because the GUID is not stored in the ENEX (which is really stupid), but YARLE already does the work of figuring out these Note Links so it can fix/update internal links. Deriving the GUID from the Note Link is trivial.

Justifications

1. I'm migrating to Obsidian, but will likely need to refer back to the source Evernote notes often. Having the Note Link in the template will allow me to open the original Evernote note quickly, without needing the extraneous HTML file.

2. I want to put the note GUID in the YAML metadata for each note so I can open notes directly via the Obsidian Advanced URI plugin. This will eventually allow me to redirect evernote:/// URLs to obsidian:// URLs without having to fix the thousands of links I have outside of Evernote (e.g. Hookmarks)

---

IssueHunt Summary

Backers (Total: $50.00)

• bumper314 ($50.00)

Submitted pull Requests

• #583 feat: evernote guid és evernote link in templates implemented

---

Become a backer now!

Or submit a pull request to get the deposits!

Tips

• Checkout the Issuehunt explorer to discover more funded issues.
• Need some help from other developers? Add your repositories on IssueHunt to raise funds.

[github-actions]

Yihaa, thank you for reporting me this issue and to let me improve Yarle!

[akosbalasko]

Hi @bumper314 ,

It's a cool one, I hope I can find time to implement it soon, probably around the beginning of the next week.
Cheers,
akos

[bumper314]

I just wanted to follow up on this one, as it's critical for my own migration from Evernote, which grows increasingly dire as Evernote started logging people out of Legacy clients this week. Do you have a bug bounty system so I can throw some bucks at getting this implemented? Thanks.

[akosbalasko]

hi @bumper314 ,
Thanks for the offer, yes, Yarle is on issuehunt for bounties: https://oss.issuehunt.io/r/akosbalasko/yarle

[issuehunt-oss]

@bumper314 has funded $50.00 to this issue.

---

• Submit pull request via IssueHunt to receive this reward.
• Want to contribute? Chip in to this issue via IssueHunt.
• Checkout the IssueHunt Issue Explorer to see more funded issues.
• Need help from developers? Add your repository on IssueHunt to raise funds.

[akosbalasko]

Hi @bumper314 ,
Currently I'm implementing this feature, and I have a question:
Do you want to add internal links interpreted as links in Obsidian also? Because if I add [[ ]] to evernote:// protocol, my Obsidian config doesn't recognize it, and of course doesn't redirect to Evernote. I'm not sure how to resolve it as it looks like that it tries to recognize it as a file (file:// protocol).

I mean currently I have this plain-text:

Is this your desired format?

[bumper314]

Hi @bumper314 , Currently I'm implementing this feature, and I have a question: Do you want to add internal links interpreted as links in Obsidian also? Because if I add [[ ]] to evernote:// protocol, my Obsidian config doesn't recognize it, and of course doesn't redirect to Evernote. I'm not sure how to resolve it as it looks like that it tries to recognize it as a file (file:// protocol).

evernote:// links work fine when using the external link format [](). Since these are template replacements, presumably a user can choose to markup the link or keep it as just plain text. For my use-case, I plan to have it in a header property, which automatically makes it a clickable link.

I mean currently I have this plain-text:

Is this your desired format?

Looks good to me!

[akosbalasko]

Hi @bumper314 ,
First of all, thanks for funding this feature, I really appreciate it!

I think it's ready, I released it in version 6.5.0: https://github.com/akosbalasko/yarle/releases/tag/v6.5.0
I summarized what you need to do to make it work (create a Table of Contents) here: https://github.com/akosbalasko/yarle/blob/master/Templates.md#extra-template-blocks-if-there-is-toc

Pls verify that it works for you, or If you face with some issues, bugs or anything, of course, feel free to contact me, and I'll fix it asap.

[bumper314]

@akosbalasko Thanks so much!

There is an issue with the evernotelink replacement. I see in many of my notes that the Evernote Note Link URL (which I'm using in the YAML properties header as part of the template) is become malformed like evernote:///evernote____view150249720/s714/0a61cf37-91ee-4b55-bfda-1f0795c20b91/0a61cf37-91ee-4b55-bfda-1f0795c20b91/. This seems to happen about 95% of the time, and I can't determine a pattern.

Here's my template and config: https://gist.github.com/bumper314/9bafa3cefbf514cfa735e88b9b6ecac8

[akosbalasko]

@bumper314 ,
Hmm that's strange. I've run my tests agains your config and everything looks fine at my side. So I think there are two options: The links were malformed before the conversion (in the enex file), or they are overwritten after the conversion (by a plugin or something in Obsidian).

So, ito check that this replacemenet is produced by Yarle,could you pls close Obsidian, run the conversion and check the produced file via a plain text editor?
If the URLs are malformed there as well, could you pls share me an enex file that contains only one note which produces the same issue?

[bumper314]

@akosbalasko I'm working to find a reproducible test case for you. It happens every time with my whole Evernote export (11k notes), but I can't seem to get it to happen with a smaller subset of notes. I setup a development environment so I can dig into the issue more.

BTW, I was seeing munged links exactly like this even when I first tried YARLE 5.2 back in July, so I don't think the issue is related to your recent changes.

The links were malformed before the conversion (in the enex file)

That wouldn't appear to be true, because isn't the {evernotelink} template replacement being constructed by YARLE from the Table of Contents? I've inspected the Table of Contents notes in my .enex export, and the links all look valid.

or they are overwritten after the conversion (by a plugin or something in Obsidian).

I'm seeing the munged links from a fresh export, before opening the vault in Obsidian.

[akosbalasko]

@bumper314 ,

Aham, alright. Feel free to send me the whole enex if you don't mind and you don't have sensitive data in it, and I can dig into there (too).
here is my email address: akos0215@gmail.com

[akosbalasko]

@bumper314 ,
hehe, oops, I was thinking that 11k means 11 kbyte, not 11.000 :D :D Sorry, late night here.

[akosbalasko]

@bumper314 Which Evernote version do you use? Maybe it is related.

[akosbalasko]

The interesting point is that an Evernote link should look like this:

evernote:///view/76136038/s12/4d971333-8b65-45d6-857b-243c850cabf5/4d971333-8b65-45d6-857b-243c850cabf5/2cd4dc67-1d52-401f-9aad-d5524b646ba2

But the generated one is this:

evernote:///evernote____view150249720/s714/0a61cf37-91ee-4b55-bfda-1f0795c20b91/0a61cf37-91ee-4b55-bfda-1f0795c20b91/

So the question is: how the send "evernote" (and the underscores) was added? And the slash is missing between view and the id.
I searched for "evernote" string in the codebase and no such string anywhere.

[akosbalasko]

In the worst and fully dirty way I can improve the code to replace

evernote:///evernote____view

by this:

evernote:///view/

but it is a workaround.
If you don't find any clue, I'll do this tomorrow.

[bumper314]

@bumper314 Which Evernote version do you use? Maybe it is related.

Evernote 7.14 (458244 Direct) on Mac, but I was also seeing this issue with exports from 6.8 and 7.2.3 with YARLE 5.2.

For a valid link URL to be munged from evernote:///view/76136038/s12/... to evernote:///evernote____view150249720/s714/... makes me think the evernote:/// portion is being sanitized by something, so the colon and slash is being converted to underscore. The only place I see this might be happening is https://github.com/akosbalasko/yarle/blob/master/src/utils/turndown-rules/internal-links-rule.ts#L68, but I haven't fully debugged it yet.

[akosbalasko]

Yeah, that would be a good clue, if it would happen on 100% of the links including mines with your config. aand it doesn't answer the question of how the second "evernote" string appear there. Could you pls confirm that if you open the enex file with a text-editor you don't get any results to "evernote:///evernote____view" ?

[akosbalasko]

• on the line what you point to transforms the display name, while for the evernote link tag Yarle uses the value on the part of that function.
  The mysery is that there is a condition called IsEvernoteLink that checks whether the link starts with evernote:///view or https://evernote.com so we put the link into the ToC datastructure only if it is a valid link. Then it looks like that when we get it out, it is transformed. But there os only one case when it can be modified is to update it, so when we add a different url to the same id. but it doesn't provide anwers for the string change. Misery.
  I installed Evernote 7.14 created some notes + Table of Contents, and it looks fine for me. :/

Dummy question: does the link's label contain inline base64 encoded images?

[bumper314]

Could you pls confirm that if you open the enex file with a text-editor you don't get any results to "evernote:///evernote____view" ?

Confirmed.

Dummy question: does the link's label contain inline base64 encoded images?

Nope.

Ok, I have a reproducible test case and mostly understand the problem, though I'm not sure of the exact fix yet.

I added a bunch of debug output to apply-links.ts around the RegExp calls and found where the issue is happening:

Log output:

realFileName: evernote____view
replace in all files: /view\//g with evernote____view

Key in allLinks map:

"view/":{"url":"evernote:///view","guid":"evernote:","title":"evernote____view","noteName":"Script better Evernote link preview in iClip","notebookName":"Notes","uniqueEnd":"bWrq6"}

So I found in the "Script better Evernote link preview in iClip" note, that a code block contained the code if _text begins with "evernote:///view" then, but Evernote automatically converts things that look like URLs into real HTML links, so it was really <a href="evernote:///view">evernote:///view</a>. This caused a RegEx in apply-links.ts to naively replace all instances of evernote:///view with a sanitized evernote:///view -> evernote____view, as if the link was a note link to a file name "evernote____view" (which doesn't actually exist).

Fix Suggestion: The RegEx in apply-links.ts should be more tightly constrained, perhaps look for the entire link markup including the [[<link>]] or [[<link>||, but I'm not 100% sure of the implications of this change.

[akosbalasko]

wow, Evernote surprises me all the time. But in this case if I see well, as the real content was
<a href="evernote:///view">evernote:///view</a> in the enex file, so technically speaking Yarle did its job, the problem is that Evernote looses the real link and replaces it with this dummy stuff "evernote:///view", but at this point we have no clue about what was the original link, right?

[bumper314]

I don't think there's much you can do about this particular bad link, but I still think my fix suggestion above will help avoid the issue and other potential bugs related to link replacement.

[bumper314]

Or, you might consider doing the link replacement stuff on the HTML DOM prior to converting to Markdown. That would be much more reliable compared to RegEx.

[akosbalasko]

@bumper314
So, I think there are two issues here.

1. is that Evernote looses the real link -> we cannot solve it.
2. instead, it generates the meaningless link AND it copies the link as label. These link labels are used and stored as link "titles" in the map, and they are sanitized as well, so the title is going to be stored as "http____evernote".

So I think the issue in general is that Yarle sanitizes the Evernote links' title without question, but it may happen that the title itself is a link. And as it is a not existing file, the question now is how we should name the internal links found dead because of Evernote's failure, and how we should label them?
Any suggestions?

[bumper314]

1. Well, Evernote didn't really lose the link. For clarity, here's exactly how the link got created.

In Evernote, I was pasting some AppleScript into a code block. That code happened to have a line if _text begins with "evernote:///view" then. Evernote automatically converts text that looks like a URL into a clickable link, so even though this text was in a code block, the underlying HTML looked like if _text begins with <a href="evernote:///view">evernote:///view</a> then.

I'm currently testing a fix by changing isEvernoteLink to better validate internal links. I'll let you know how it goes.

[bumper314]

Ok, I have tested my fix and it seems pretty sound:
bumper314@9b07a19

Before I submit a PR, I would like to fix a small bug related to #498. Should I combine those, or submit two separate PRs?

[akosbalasko]

Hi @bumper314 ,
Thanks a lot,
Whichever is better/easier for you, one or two PRs, as you wish.

[akosbalasko]

Hi @bumper314 ,
Thanks for your improvement, I really appreciate it!
I merged it and released a new version, v.6.5.1