Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
bpape0 opened this issue May 15, 2023 · 4 comments
Open

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

bpape0 opened this issue May 15, 2023 · 4 comments
Labels
bug Something isn't working

Comments

@bpape0
Copy link

bpape0 commented May 15, 2023

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.
@github-actions
Copy link

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

@akosbalasko akosbalasko added the bug Something isn't working label May 16, 2023
@akosbalasko
Copy link
Owner

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!

@TjenWellens
Copy link

TjenWellens commented Nov 13, 2023

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Status: To do
Development

No branches or pull requests

3 participants