Not many wiki site engines based on Markdown work directly from git as cleanly as this.
There's a few of them though, such as this old Ruby lang standby with a decade's worth of features that a decade ago was a way to host your same GitHub Pages site locally, supporting SSO:
https://tina.io/ tinacms is very modern & well built, git markdown typescript. and headless or with template components.
it's such an epic feat, how programmers have grown up to manage source over time & changes. i very much hope this richness cam extend beyond code some day, stop being arbitrary UI we craft & become good data structures that transcend each application.
It doesn't limit itself to markdown, nor to git (you can use darcs, hg, or even sqlite). A bit long in the tooth, though -- I stopped working on it once spam started to make self-hosted public wikis untenable.
I really enjoyed Gollum for awhile, but I'm not a Rubyist, and past a certain point, every time I tried to run it or Jekyll I got dependency problems that I'd eventually solve, but without understanding. It was undoubtedly user error; I should definitely have learned and used rvm or something.
It should be noted that goolum is AFAIK still the backend behind GitLabs Wikis. It works quite well Ime and was easy to setup/use for basic Markdown Documents.
My definition of minimalistic is a SSG where you use Github's WYSIWYG editor and push changes to trigger a pipeline that rebuilds the page and uploads it to a cloud service with S3 support.
Well, in real life this setup uses Gitlab but I referenced Github because I assumed they have better WYSIWYG options than Gitlab.
And why that matters is because I can run the pipeline from my own laptop with gitlab-runner.
But we all have our own view of minimalistic and mine is "the less code is running, the more minimalistic it is". To be abundantly clear, the less code is running that I have to operate or maintain. Obviously Github, S3 and a SSG generator is a lot of code.
I was literally building my own version of this with madness this morning to go from Obsidian to web in my workflow. Thanks for speeding things up for me. Great work!
It's minimalist until you read the installation part...
As a backend SQL guy I always feel overwhelmed by "minimalist" software that actually depend on me knowing ho to deploy safely on docker or mastering N dependencies before actually having something to try. Long are gone the lamp days... they had their own set of problems (wrong versions!) but it was a simpler time where you felt a little bit more in control.
I often feel the same way. I had someone ask me to make a microservice on some platform she built. I was told it would take 10 minutes. In reality, it took a couple weeks, and then every week for a year I was getting told something was changing and I had to mess with this or that, and also attend daily meetings about the project. 10 minutes turned into 30% of my whole year. The whole platform she built lasted maybe 2 years before it was decided we needed to move on from it. It was a total waste of time.
Meanwhile, I have a little LAMP project that is used significantly more than the micro service, that I’ve run for 15 years that I only have to touch when it needs feature updates. The platform itself just works. Occasionally I’ll need to move to a newer OS, which takes a few hours to get the new server built, run the job to configure it (doing it manually doesn’t take too much longer), then submit a request to change the load balancer to point to the new servers.
Granted, some of this comes down to experience. However, needing to know all the tools involved for the microservice was much more annoying and they broke half the time.
I got it to work under Piku (https://piku.github.io) in much the same way (since I support uwsgi, that bit was trivial).
I did have to hardcode the data path, and I think having some form of export/snapshot would help as well, but submitting a patch might be a fun weekend project.
But deploying on Docker is simpler than LAMP! All dependencies included. All binaries included. You can even just tell systemd run it (also usually included).
Yeah I’m with you. I cannot stand having to jump through hoop after hoop just to get started - things to download, command line utils to install, line after line after line to copy into the terminal, layers and layers of dependencies, possibly with version incompatibilities that the “getting started” page was never updated to reflect… it’s a nightmare.
Sometimes you just want to sit down and write code and see it working.
come on, you just need to teach a bit of git/k8s/docker/tls/proxies/storage/vault/markdown/linux/apt and then your family will be autonomous at managing this wiki IF you are allowed to take vacations.
We use Confluence at work. It has the option to render HTML embedded in the page. I haven’t tried to render a whole file attached to a page, but there might be a way to do that.
I’ve used it a bit to add my own forms into pages to create little tools for people in docs.
In the past we used Jive, and I had a rather involved HTML paged embedded there. I had to be careful with my CSS, as using any generic attribute level CSS would break the platform. I hope Confluence has protections against that, but haven’t tested it, as I got in the habit of avoiding that issue all together.
Every new wiki / knowledge management system I always compare against Confluence. I get the advantage of keeping your content in plaintext for portability but when I look back on how many times I've actually ported wiki content it's... maybe once? Most systems these days are handily capable of this, in any case.
Anyway, Confluence for all its flaw has so much power, is so much more pleasant to use, your business folks won't balk at it. As often as not, we have people from all parts of the company in there, reading and writing both, and it needs to be usable to people of all technical levels. Markdown wikis and their editors don't often meet this criterion, or they're missing on some key features (tables!!).
To me, Confluence's only real down side is that it's an Atlassian product. I wish I could find something to scratch the itch without feeling the need to buy into that whole ecosystem.
Readit News
There's a few of them though, such as this old Ruby lang standby with a decade's worth of features that a decade ago was a way to host your same GitHub Pages site locally, supporting SSO:
https://github.com/gollum/gollum
https://github.com/gollum/gollum/wiki/Gollum-via-Rack-and-CA...
it's such an epic feat, how programmers have grown up to manage source over time & changes. i very much hope this richness cam extend beyond code some day, stop being arbitrary UI we craft & become good data structures that transcend each application.
https://hackage.haskell.org/package/gitit-0.15.1.2
It doesn't limit itself to markdown, nor to git (you can use darcs, hg, or even sqlite). A bit long in the tooth, though -- I stopped working on it once spam started to make self-hosted public wikis untenable.
personally i prefer confluence though. just find it faster to dump things out.
https://github.com/Linbreux/wikmd
I can’t remember why I switched from gollum to wikmd. I suspect installed size might be why.
incredibly important suggestion: replace "utterly" with "otterly"
And why that matters is because I can run the pipeline from my own laptop with gitlab-runner.
But we all have our own view of minimalistic and mine is "the less code is running, the more minimalistic it is". To be abundantly clear, the less code is running that I have to operate or maintain. Obviously Github, S3 and a SSG generator is a lot of code.
As a backend SQL guy I always feel overwhelmed by "minimalist" software that actually depend on me knowing ho to deploy safely on docker or mastering N dependencies before actually having something to try. Long are gone the lamp days... they had their own set of problems (wrong versions!) but it was a simpler time where you felt a little bit more in control.
Old man yell at the clouds I guess...
Meanwhile, I have a little LAMP project that is used significantly more than the micro service, that I’ve run for 15 years that I only have to touch when it needs feature updates. The platform itself just works. Occasionally I’ll need to move to a newer OS, which takes a few hours to get the new server built, run the job to configure it (doing it manually doesn’t take too much longer), then submit a request to change the load balancer to point to the new servers.
Granted, some of this comes down to experience. However, needing to know all the tools involved for the microservice was much more annoying and they broke half the time.
https://boringtechnology.club/
I did have to hardcode the data path, and I think having some form of export/snapshot would help as well, but submitting a patch might be a fun weekend project.
Deleted Comment
Sometimes you just want to sit down and write code and see it working.
Otter is much nicer, though.
I used https://foswiki.org and it was great for combining structured and non structured information
The irony I'm having is that I store some single file html documents alongside my notes and none of these engines (or obsidian) will render them!
I’ve used it a bit to add my own forms into pages to create little tools for people in docs.
In the past we used Jive, and I had a rather involved HTML paged embedded there. I had to be careful with my CSS, as using any generic attribute level CSS would break the platform. I hope Confluence has protections against that, but haven’t tested it, as I got in the habit of avoiding that issue all together.
Anyway, Confluence for all its flaw has so much power, is so much more pleasant to use, your business folks won't balk at it. As often as not, we have people from all parts of the company in there, reading and writing both, and it needs to be usable to people of all technical levels. Markdown wikis and their editors don't often meet this criterion, or they're missing on some key features (tables!!).
To me, Confluence's only real down side is that it's an Atlassian product. I wish I could find something to scratch the itch without feeling the need to buy into that whole ecosystem.