[Bug]: <img>'s src aren't getting a base path correctly (attachmentLinks)

[kurko]

Issue validation

• My issue is not a question relative to Material Mkdocs nor Mkdocs (You can open a discussion to get more help!)
• I checked the issue to prevent duplicate
• I checked my configurations files and the documentation

Workflow

Obsidian plugin 💠

Describe the bug

tl;dr with Default Attachment Folder (defaultImageFolder) set to images/obsidian, dev console shows that convertLinkCitation ignores that and returns images/naming.png instead of images/obsidian/naming.png .

It seemed to be similar to #8, which was supposed to be fixed by 0755d37, but it wasn't.

Upon investigation, I think the culprit is this line. It was supposed to be using the default attachment path and is not. It's returning images/naming.png

You can see in the generated PR that the image path is correctly images/obsidian/naming.png, but the markdown file itself is not including obsidian/ in src.

How to reproduce ?

1. Set a default attachment folder (defaultImageFolder)
2. publish
3. the image tag doesn't have its path modified to include the attachment folder. It ignores it completely.

Configuration

{
  "githubRepo": "blog",
  "githubName": "kurko",
  "GhToken": "ghp_[REDACTED]",
  "shareKey": "share",
  "ExcludedFolder": "",
  "fileMenu": true,
  "editorMenu": true,
  "downloadedFolder": "fixed",
  "folderDefaultName": "obsidian",
  "yamlFolderKey": "",
  "rootFolder": "",
  "workflowName": "",
  "embedImage": true,
  "defaultImageFolder": "images/obsidian",
  "autoCleanUp": true,
  "autoCleanUpExcluded": "",
  "folderNote": false,
  "convertWikiLinks": true,
  "convertForGithub": true,
  "subFolder": "",
  "embedNotes": false,
  "copyLink": false,
  "mainLink": "",
  "linkRemover": "",
  "hardBreak": false,
  "logNotice": false,
  "convertDataview": true,
  "useFrontmatterTitle": true,
  "censorText": [
    {
      "entry": "\\]\\(\\.\\/",
      "replace": "]({% link obsidian/"
    },
    {
      "entry": "\\({% link(.*)\\)",
      "replace": "({% link $1.md %})"
    }
  ],
  "inlineTags": false,
  "dataviewFields": [],
  "excludeDataviewValue": [],
  "metadataFileFields": [
    "obsidian"
  ],
  "frontmatterTitleKey": "filename",
  "shareExternalModified": false
}

Relevant log output

No response

OS

MacOS

Anything else?

Minor feedback: the lack of tests make it difficult to contribute

[kurko]

Found the culprit: apparently targetList.filter((x) => !sourceList.includes(x)) is removing the word obsidian from images/obsidian/naming.png. I don't understand why it needs to drop a directory, unsure whether it's a feature for something else or a bug.

Here's the screenshot with all values. Notice at the end, it drops the directory:

Can you advise on how to fix this? I'm afraid it'd break other things that are expected somewhere else 😬 This is the last remaining block to get my blog to get published from Obsidian 😄

[Mara-Li]

I Will check that ! Don't worry :D

[Mara-Li]

I pushed a beta version of this fix, could you please try it and keep me informed about it ?

[kurko]

I can confirm it worked with 4.3.7-0 (beta) 😄

[kurko]

I noticed now that links aren't working, and I think it might be due to this change (need to confirm).

Here's my config:

---

Here is the screenshot in Obsidian showing from about (source) to my-digital-workbench (target).

Note that:

• the my-digital-workbench file has frontmatter filename: _pages/my-digital-workbench (with _pages),
• the file is deployed to obsidian/_pages/my-digital-workbench as expected,
• but the final link in about points to obsidian/my-digital-workbench, omitting _pages.

[Mara-Li]

As I can see, It's not a markdown or wikilinks no ? My regex for internal links only work on these

[kurko]

Hm... yes it is. If you check again this image, the wikilink [[my-digital-workbench|Check out my work setup]] on the bottom right pane is a link.

[BluesDriveAmelia]

This seems to be the same issue I'm currently struggling with. The image links in my posts start with "/posts/" but the images are at the same link but without that. I was actually following your blog post, @kurko, though what I assume was the solution you figured out (the text replacer) has not been working for me. Any ideas?