My Digital Garden Setup
This page is dedicated to my current website setup, my customizations, bugs, rough edges which still exist and potential workarounds.
The Setup
- I write texts within Obsidian.md.
- I use the plugin Obsidian Digital Garden, which publishes notes of my choosing firstly into a GitHub Repository.
- Said repo is derived from this template, which houses an 11ty project.
- 11ty produces a static page which is then deployed with GitHub Pages.
Issues, Bugs and Customisations
Here I track any issues I've encountered so far and how I deal with them.
Whenever possible, I want to fix issues directly in Obsidian, so that my Obsidian view of the texts I publish stays close to what is actually produced.
The next best thing is to customize the Digital Garden template the way it's meant to be customized, to avoid hassle when updating the template in the future. If the customization options are not sufficient, I look next at fixing this in the files outside of the customization paths in the template, which comes at the price of overhead when updating the template.
If it's not fixable in the template, the last resort is fixing this in the plugin directly.
Deploying to GitHub Pages
Status: Resolved ✅
Description: The plugin is mainly aimed at Vercel, and lists Github Pages only somewhere in the "Other" section. There is no documentation on how to deploy to GitHub Pages.
Solution:
- Clone the Template Repository. It needs to be public, and it needs to be named
(yourname).github.ioas per the GitHub Pages Documentation. - Follow the set up of the Digital Garden plugin to connect Obsidian to that repository.
- In the repository settings, under "Pages", finish the setup of the page. As "Source", select "GitHub Actions".
- If GitHub comes with its own workflow, remove it (you can do this in the Actions tab in GitHub). You should also remove the build workflow the template comes with by deleting
.github/workflows/build.yamlfrom the repository. - Place the
main.yamlfrom below into.github/workflows/to activate the workflow that builds the site. - Done!
main.yaml
name: GH Pages
on:
push:
branches:
- main # Set a branch name to trigger deployment
# Allows you to run this workflow manually from the Actions tab
workflow_dispatch:
pull_request:
permissions:
contents: read
pages: write
id-token: write
concurrency:
group: "pages"
cancel-in-progress: false
jobs:
deploy:
environment:
name: github-pages
url: ${{ steps.deployment.outputs.page_url }}
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup Node
uses: actions/setup-node@v4
with:
node-version: '23'
- run: npm install
- run: npm run build
- name: Setup Pages
uses: actions/configure-pages@v5
- name: Upload artifact
uses: actions/upload-pages-artifact@v3
with:
path: 'dist'
- name: Deploy to GitHub Pages
id: deployment
uses: actions/deploy-pages@v4
404 Pages don't work properly
Status: Resolved ✅
Description: For internal broken links, the Digital Garden links correctly to its 404 page. For invalid URLs, the default GitHub Pages 404 is displayed.
Solution: Add the following front matter to the src/site/404.njk:
---
permalink: 404.html
---
Formatting breaks if there is no line break above a heading
Status: Worked around ✅
Description: Obsidian renders just fine if you put content directly above a heading, but formatting for a Digital Garden note breaks in this case.
Solution: I am using Obsidian Linter anyways , so all I had to do was to enable the rule "Heading Blank Lines". This prevents the offending formatting from happening.
Inefficient Transclusions
Status: Worked around ✅
Description: The plugin doesn't cache transclusions, so if you transclude e.g. a header in every note, then that header file is compiled for every single note again. This results in performance degradation during publishing.
Solution: Using transclusions as a header has other drawbacks as well, such as the header showing up in the RSS Feed or the built-in search. The Digital Garden plugin has a capability to add custom components, such as a Header, which I used instead of transclusions.
Regular Dataviews produce bogus output
Status: Worked around ✅
Description: Dataviews sometimes produce a single { .block-language-dataview} below the desired result.
Solution: I migrated to JS Dataviews first, but I ran into performance issues. Instead, I now remove that line during markdown pre-processing. I do this by extending the userMarkdownSetup in the template file src/helpers/userSetup.js as follows:
function preProcessRule(state) {
let currentContent = state.src;
currentContent = currentContent
.split('\n')
.filter(line =>
!line
.trim()
.startsWith('{ .block-language-dataview}'))
.join('\n');
state.src = currentContent;
}
md.core.ruler.before('normalize', 'user_markdown_preprocessor', preProcessRule);
This removes the offending line.
JS Dataviews have performance issues
Status: Partially Resolved ⏳
Description: JS Dataviews come with a significant performance overhead, as a JS environment needs to be spun up for every note that uses one. I had JS Dataviews in every file, which increased the compile time (needed for publishing) from seconds to minutes.
Solution: since most of these dataviews were built to create some kind of header or footer, I replaced most of them with custom components, as described above. There are still some dataviews remaining that I need to migrate.
Other Issues
These are other issues I encountered. I will expand on all of them once I find the time.
- Feed and Sitemap producing invalid output
- dv.current() is empty
- DataView uses locales inconsistently, leading to wrong date parsing
- built-in header components (timestamp, tags, H1) have issued
- compile fails if permalink is number
- secondary rate limit hit on publishing many files
- Kebab-case front matter not recognized
- The permalink needs to stay stable even If the title isn’t
- I want to see the title in my file, but the setup prevents me to do so
- Publishing on mobile leads to app reload
- Linking to header in same note doesn’t work
Last Update:
philippflenker.com was last updated .
👾