Use of empty curly braces in .md causes build to fail

[gerteck]

Please confirm that you have searched existing issues in the repo

Yes, I have searched the existing issues

Any related issues?

No response

Tell us about your environment

Windows 11

MarkBind version

5.5.3

Describe the bug and the steps to reproduce it

Use of {{ }} in 2025 course website caused the build process of the markbind site to fail.

Doing:

• \{{ }} still causes it to fail
• `{{ }}` also fails
• \{ \{ } } is ok

Perhaps it is possible to make the build process more resilient? Or log an error or warning mentioning the empty braces. Also relates to github action issue where build and deployment shows success even though build / github deployment actually failed

Expected behavior

No response

Anything else?

No response

[gerteck]

I realized it's related to https://markbind.org/userGuide/tipsAndTricks.html#using-raw-endraw-to-display-content

It's probably a known issue and maybe not exactly a bug.

Though, i think it could be relevant to make the documentation a bit more user friendly and add {% raw %} {{ content }} {v-pre} {% endraw %} to use it as a raw string by itself.

Also maybe it is worth pointing this specific bug out in troubleshooting? Rather than tips and tricks. I also think it could be helpful to add a FAQ or expand the troubleshooting session? as when making new markbind sites and deploying github pages I keep troubleshooting the same rookie mistakes like not updating baseURL to site.json, branch change from master to main, or adding {{ baseurl }} to diagrams etc. etc. ?

[lhw-1]

Though, i think it could be relevant to make the documentation a bit more user friendly and add {% raw %} {{ content }} {v-pre} {% endraw %} to use it as a raw string by itself.

Definitely, we can & should do this.

Also maybe it is worth pointing this specific bug out in troubleshooting? Rather than tips and tricks. I also think it could be helpful to add a FAQ or expand the troubleshooting session? as when making new markbind sites and deploying github pages I keep troubleshooting the same rookie mistakes like not updating baseURL to site.json, branch change from master to main, or adding {{ baseurl }} to diagrams etc. etc. ?

That's a good point - perhaps we can simply merge the troubleshooting and the tips and tricks sections into a single "Troubleshooting & FAQs" section? And maybe re-organize it for better flow. We should do this if, as you say, at the moment both pages are mostly used for troubleshooting anyway.

[damithc]

That's a good point - perhaps we can simply merge the troubleshooting and the tips and tricks sections into a single "Troubleshooting & FAQs" section? And maybe re-organize it for better flow. We should do this if, as you say, at the moment both pages are mostly used for troubleshooting anyway.

Hmmm... in principle, they are two different things. We don't want to send readers to a 'troubleshooting' section more often than they strictly need to. It should be a section users rarely go to, if ever.
We can use MarkBind's reuse features to deal with any overlaps between Tips, FAQs, Troubleshooting, etc.

[lhw-1]

I think there are two points that need to be addressed:

1. There are some subsections, namely the raw-endraw and the deployment subsections, that might also cause errors that lead users to visit the troubleshooting section instead. For this, we could include these subsections in the troubleshooting section.

2. Relating to this part in particular:

I also think it could be helpful to add a FAQ or expand the troubleshooting session? as when making new markbind sites and deploying github pages I keep troubleshooting the same rookie mistakes like not updating baseURL to site.json, branch change from master to main, or adding {{ baseurl }} to diagrams etc. etc. ?

It might be useful to have a general section (like a summary / tl;dr section for setups) that contains common issues / reminders when setting up pages. If we want the troubleshooting section to be a section where users rarely go, then we might need another section for this (a page where we want users to frequently use, essentially). I think this idea is in line with previous discussions in #2257 and for #2459. This was why I initially suggested consolidating the troubleshooting & tips and tricks section, but since they do serve different purposes, it might be better to have a separate section for this.

---

It'd be better to keep the scope of this particular issue to point 1, but I think point 2 brings up another aspect of the user documentation that we can address going forward.

[gerteck]

Thank you for the insights! I agree with the notion that the troubleshooting section shouldn't (optimally) be something that users should look to go to! (Did not think of that). Looking back, I realized that the user/dev guide is quite comprehensive, but the issue was that I didn't know where to look because I didn't know the specific term to search.

I think this just highlights the importance of having a full text search available (which I am refining now!).

The use of the reuse to highlight common errors sounds like a good idea.