breadcrumbs: Bug: "Type mismatch, expected text" in properties field
Describe the bug
Breadcrumbs writes the properties as down: ['My File'] instead of down: "[[My File]]", causing Obsidian to create a small warning with the message Type mismatch, expected text. The name of the referred file in the property does not appear as a link either, but breadcrumbs seems to work otherwise as expected and can be navigated in the matrix view.
To Reproduce In a new Obsidian vault, with only breadcrumbs installed, and a default configuration where we enable writing all relationships to the files.
Given two files My Parent File and My Child file, if I set the relationship of both files by writing only to the child the following:
---
up: "[[My Parent File]]"
---
and then ask breadcrumbs to regenerate the indices and write to all files, the content of the parent file is written as:
---
up: ['My Child File']
---
Expected behavior
Links are written to the property field in the "[[Name of file]]" format instead, such that obsidian recognizes it as a working link. In the above example, I would have expected up: "[[My Child File]]" instead of up: ['My Child File'].
Screenshots
Desktop (please complete the following information):
- OS: Manjaro (Linux)
- Obsidian 1.5.3
- Breadcrumbs 3.6.11
Additional context
After some more experimenting, if the files are located in folders and subfolders, writing the hierarchy can become quite mangled. I believe this can be because BC likely checks if the files are already written in the hierarchy, but because the strings "[[File]]" and ['File'] are not the same, it writes it twice. However, this bug might be unrelated and warrant its own issue ticket.
This is from another vault. The blue links I added manually and are of the type
"[[File]]" , the white links are the ones added by BC and are of the type ['File']
On the other hand, I’m completely new to Obsidian. I’ve searched thoroughly for this bug, but maybe I don’t know the correct keywords to identify it and google yields no useful results.
About this issue
- Original URL
- State: closed
- Created 4 months ago
- Comments: 17 (10 by maintainers)
I’m gonna close out the original issue as complete. V4 isn’t fully live, but is quite stable at this point. Thanks again for all the detail! Please do share any V4 feedback, it’s really helpul 😃
Yeah, nice 😃
Indeed, the
contentfield isn’t implemented yet!Oh cool! Yeah, that integrates really well, thanks for sharing. Gonna point to this issue #504 for when I update the docs on this feature
Oh no! This is my bad. I read you, then went on with my usual stuff, and when I came back to this i had a nagging feeling I was forgetting something about how the property was spelled (hence my question). Thanks! I can confirm that it does indeed work 😃
As for giving a special meaning to the name of the file, maybe it’s now even needed if the user sets up a template. Once everything is in place, there is no need to recurse downwards
I can confirm that with 1100 .MDs its working nicely 😄 It never takes more than 10-30 ms to regenerate the breadcrumbs (on a 11th gen i7 laptop).
Sorry that I hijack this thread. Can you confirm that Folders can be used as the source of edges? I can’t find where to enable this option but it shows as done in
v4.md. If it should indeed be enabled, I’ll open a new ticket with a full report 😃Of course feel free to test the beta version using BRAT, and let me know your thoughts 😃 Keep it open for now. I’ll go through and close out any resolved issues once v4 is live.
Hey, thanks for the detailed issue! I’m rewriting the plugin from scratch, please see the
V4.mdfile in the root of the repo for more info. A couple of the issues you mentioned here are resolved in the new version