Open jwhitley opened 2 weeks ago
This plug-in requires you to list every folder you might have an image in individually (with full path for each sub folder) in it's settings for it to find an image in your vault. As in if you put / for root it will only search the top level of that folder and no other sub folder. If you have a /media/instructables folder you need to list that full path as a folder to search. If you didn't set that up, it won't find the images. I'm unsure if that's what you're encountering since it wasn't listed in your steps, but I wanted to mention. I'm really hoping they change this so it'll just get all image files from the entire vault or at least search subfolders, but for now you need to list every folder.
@Graywaren Thanks, that clarifies things. I’d just assumed it was a set of recursively searched image directories mostly because that’s kinda what everything does. I’m using the Local Images Plus plugin, which imports external web assets into note-specific folders… so an explicit list of every leaf folder with images is super unworkable.
I think this could probably be an easy fix, but I'm currently super busy with work and unable to work on this feature at the moment. Can try when I have time, but code contributions are also always welcome! Perhaps can use a * at the end of a path if we want to include all subfolders (or could make it default behavior, Id just have to think if there are any cases where this could cause problems...).
@jpoles1 I think the path forward here is to drop this configuration entirely and simply leverage Obsidian’s idiomatic link path matching, ala how [[…]]
file finding works. The relevant snippet go from [[filePath]]
to a TFile
is:
var linkpath = getLinkpath(filePath)
var tfile = this.app.metadataCache.getFirstLinkpathDest(linkpath, filePath)
If a user needs to constrain the litegal
block to a specific subset of the vault (e.g. there are multiple folders with image001.jpg
), these can be path prefixed to disambiguate them just like regular wikilinks.
I’ll work up a PR to test this approach out.
Setup: Obsidian 1.7.5 with Electron 32 installer (macOS)
Repro steps
webp
images, FWIW.litegal
code block. I then edited this to remove the![[
prefix and]]
suffix for each image, so just the image names are present in the code block.Actual results
Lite Gallery reports "No images found" for the block rendering, and pops up Obsidian alerts
Lite Gallery: Image not found: [...]
for each image in the block. Yet the same images inlined as![[<image name>]]
from the original drag are found and render just fine.Expected results
The images are found and the Lite Gallery renders.
Sample Markdown