yarle icon indicating copy to clipboard operation
yarle copied to clipboard

No output when using link-to-original (HTML) in template

Open bpape0 opened this issue 1 year ago • 4 comments

yarle v5.1.0

Problem:

When using the {link-to-original} (inside of a {link-to-original-block} block), yarle is not creating any output files.

typical log entry

Conversion started at Mon May 15 2023 13:30:31 GMT-0700 (Pacific Daylight Time)
Converting note "test note"...
Failed to convert note: test note, {"errno":-2,"syscall":"scandir","code":"ENOENT","path":"/Users/user/Documents/evernote/obsidian/test1/attachments"}
Conversion finished at Mon May 15 2023 13:30:31 GMT-0700 (Pacific Daylight Time)
Note "test note" converted successfully in 0.085 seconds.
Notes processed: 1

root cause

The issue (as implied by the error message) is that yarle is not creating the resources directory (as specified by the resourcesDir configuration directive in the yarle config.json file) prior to attempting to create the .html output.

mitigation

  1. Run the conversion once (which ultimately does nothing but create empty directories for each processed .enex file)
  2. Manually create the appropriately named resources directory
  3. Run the conversion again
  4. Both the .md file and associated .html file are properly created.

bpape0 avatar May 15 '23 20:05 bpape0

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

github-actions[bot] avatar May 15 '23 20:05 github-actions[bot]

Hi @bpape0 ,

Thank you for reporting this issue!

You're right, the root cause is the missing resourceDir, but I'm not sure how your config takes effect on the folder creation My problem is that Yarle offers a configurable option to store your resources globally (I mean on enex-file lever or on top of it ), and in this case, the problem would be that the html files are not stored there somehow. If they are not set, (e.g yarleOptions.haveEnexLevelResources and yarleOptions.haveGlobalResources are false), then the proper resource directory should be created, but - as they are not in your case, the root cause points to a different problem.

So, therefore I would like to ask you tosend me your config file (at the beginning of the logs). Thank you!

akosbalasko avatar May 17 '23 06:05 akosbalasko

Some extra details I discovered.

Prerequisites for the bug:

  1. config with "haveGlobalResources": true,
  2. template with {link-to-original-block} html: "[[{link-to-original}]]"{end-link-to-original-block}

Bug:

yarle's {link-to-original} causes problems when configured with "haveEnexLevelResources": false. seems like regardless of haveEnexLevelResources and haveGlobalResources, the html files will be stored inside as if "haveEnexLevelResources": true, but crash if the config does not have "haveEnexLevelResources": false because the folder will not be created.

Mitigations: A) @bpape0's suggestion: create that folder manually. B) Set "haveEnexLevelResources": true, "haveGlobalResources": false, in the config.json, which puts ALL resources inside the notebook folder.

Fyi: setting both to true does not work, because it behaves the same as

	"haveEnexLevelResources": false,
	"haveGlobalResources": true,

Fyi: setting both to false does work, because it behaves the same as

	"haveEnexLevelResources": true,
	"haveGlobalResources": false,

Fyi: to make the link-to-original be a link in frontmatter, I had to wrap {link-to-original} in "[[...]]" my template.tmpl:

---
{title-block}    title: "{title}"{end-title-block}
{tags-array-block}    tags: {tags-array}{end-tags-array-block}
{created-at-block}    createdAt: {created-at}{end-created-at-block}
{updated-at-block}    updatedAt: {updated-at}{end-updated-at-block}
{source-url-block}    sourceUrl: {source-url}{end-source-url-block}
{location-block}    location: {location}{end-location-block}
{link-to-original-block}    html: "[[{link-to-original}]]"{end-link-to-original-block}
---
{title-block}# {title}{end-title-block}

{tags-block}{tags}{end-tags-block}
---
{content-block}{content}{end-content-block}

TjenWellens avatar Nov 13 '23 15:11 TjenWellens

Another part to this bug. Which invalidates the alternative workaround (B) that I proposed.

The resources folder is only created once a note is processed that has a resource.

So if you have a most recent note without a resource (img / attachment /...), (seems that notes are processed in creation order, or that happens to be how evernote exports if for me) that note will fail, even when setting

	"haveEnexLevelResources": true,
	"haveGlobalResources": false,

because the resources folder is only created when it is needed for the first resource. (and the html page from {link-to-original does not trigger this)

So if you use workaround (B): All notes processed before a note with a resource, fail. The note with a resource succeeds. (because it created the resource folder before attempting to store the html from {link-to-original) All notes processed after a note with a resource succeed. (because the resource folder is now created) -> I assume that this pattern will be repeated per evernote notebook.

TjenWellens avatar Nov 15 '23 11:11 TjenWellens