Hello, I currently use a file tree structure so it’s easy to find files, say under folder A → folder AB → folder AC → file with info.
I’ll copy the file into Logseq, however I am wondering how I might find these files if they’re no longer in a file tree structure?
I’m expecting the bi-directional graph to provide a better view of all files and to link possible useful info, but also don’t want to lose the ‘old way I find stuff?’.
Feel like I’m missing something?
Welcome back @Ken!
In Logseq, you don’t organize notes with folders. You organize in outlines on pages.
I recommend your read through the onboarding guide in the Handbook (in Logseq, click the ? in the bottom right corner, then go to Handbook and read the Getting Started articles). There you’ll see the recommend way of structuring notes in Logseq. And as you’ll see, an outliner like Logseq is a very different paradigm compared to a tradition file-and-folder structure.
1 Like
“I’ll copy the file into Logseq”, not the folders.
Yes, I’m aware Logseq doesn’t use folders, rather uses pages.
I’m trying to anticipate whether the effort of copying over files into pages will not lose access to the knowledge.
Whilst I know that path to files with A → AB → AC → file, I may not know how to find some information when stored in Logseq Pages (not folders).
If these are markdown files, you can append the path of each file into its front matter before importing into Logseq. This information can then be reorganized manually, accessed with queries, etc.
1 Like
Thank you, however I’m unclear?
Could you please provide an example on appending the path? My understanding is that file.md will be renamed to fileAppendedName.md
What does ‘into its front matter’ mean please?
You’d add something like prev-hierarchy:: A/AB/AC at the beginning of each .md file. Scripting can be helpful if you have many files for import and don’t want to process each manually.
Using namespaces (e.g. filename: A/AB/AC/My Note.md) is a plausible alternative iff your folder structure is quite shallow.
Forum search, search engines, and even AIGC tools like Perplexity, can be helpful here. Frontmatter refers to file metadata specified at the beginning of file data, and many markdown-compatible programs are able to parse frontmatter. Logseq page properties, which is always the top block of a page, is a variety of markdown frontmatter.
1 Like
I’m not an expert, but based on my experience, here are a couple of things you could experiment with:
- You can create hierarchical relationships between pages using
/in the page names, and then use the extension Favorite Tree. If the top-most page in a hierarchy is favorited, all sub-pages can be viewed as a tree in the sidebar. (Note that it’s currently a little finicky – you have to click just to the left of the hierarchy arrow to expand the hierarchy.)- Better yet, you could also use the Favorite Tree plugin together with hierarchical (or “nested”) tags, creating a tag for each “folder” (e.g.,
#folder/subfolder). Favorite the parent tag, and then view the hierarchy in the sidebar. (With this approach, however, the pages themselves wouldn’t necessarily be visible in the sidebar hierarchy.)
- Better yet, you could also use the Favorite Tree plugin together with hierarchical (or “nested”) tags, creating a tag for each “folder” (e.g.,
- Assuming you’re using Markdown, you could also open your Logseq database in Obsidian, and then create the folders you want as subfolders under the Logseq-created “pages” folder. The folders will not be visible from within Logseq, but the pages within those subfolders will still be visible to Logseq. (You could also potentially use this approach to import a folder-page hierarchy into Logseq.) But this probably isn’t a real solution since it doesn’t make the hierarchy visible within Logseq.
The steps I would suggest (some already mentioned by others):
- Rename any identically-named files or folders.
- That could be a temporary step, until you have something working.
- When things work, could use namespaces for disambiguation.
- This is what namespaces are for.
- They are not ideal for folders.
- This is what namespaces are for.
- Create a Logseq page for each folder.
- On each folder-page, add a page-property that points to its direct parent folder-page.
- e.g.
parent-folder:: [[folder1]] - Top-level folder-pages don’t need that.
- e.g.
- On every page to be imported, add a page-property that points to its direct parent folder-page.
- e.g.
parent-folder:: [[folder2]]
- e.g.
- Avoid mentioning on every page all its ancestors, prefer mentioning only the direct parent(s).
- Import the pages.
- Avoid placing new pages into this hierarchy.
- Prefer embracing Logseq’s graph structure.
- Allow pages to have multiple direct parents and participate in multiple loose hierarchies.
- Don’t think ahead about them, let them be formed during usage.
1 Like
Thanks, working on it, need to fix the constant challenge of the sync breaking first.
Where can I notify of a typo in the Logseq instructions?
I’m reading the articles: Getting Started → Fundamental 1: Write in blocks and branches → 6. Sibling blocks → are blocks that are are on the same indentation level under the same parent.
Only one “are” is needed, the duplicate “are” needs to be deleted.
1 Like
Thanks @Ken, very sharp! I’ve fixed the typo.
If you (or anyone else) wants to contribute to the Handbook, here’s the GitHub repo: GitHub - logseq/handbooks: Handbooks resources for Logseq.
Please send me a DM on this forum or send an email to support@logseq.com if you’ve done a pull request.
1 Like