I think most static blog platforms offer no editing facilities on the web server, so they don’t need to worry about that side of things at all. A static wiki with no server-side editing would be fairly limited in utility. IkiWiki offers web-side editing via CGI. That might be one reason few people have bothered implementing such a system.
A static wiki with no server-side editing would be fairly limited in utility.
I’ve been thinking that using git as the backend that triggers rebuilds of the static wiki might be a working solution, at least for some kind of an audience.
That’s true. For https://ikiwiki.info, IkiWiki’s homepage, you can actually do that. Not only that, but that site is actually the doc sub-directory in IkiWiki’s actual source code repository, and they have untrusted git push set up for the site… the git hooks prevent you from committing outside of doc. But I’ve still always thought this was brave or foolish.
In my opinion, quite the opposite.
I’ll give a concrete example:
I had my own setup for experimenting with the Nim language, including the tool chain, editors, shell configuration, etc.
I had to maintain this for two different systems (macOS and Linux), including different shell semantics, package managers, binary cross compilation and testing.
Now I only have to maintain a single container which I can use in both environments. With the added benefit of immutability (ie changes to my “real” system don’t interfere with my sandbox).
I find it weird how many static blog/cms platforms there are, and how few wiki platforms. They shouldn’t be terribly different in terms of difficulty?
I think most static blog platforms offer no editing facilities on the web server, so they don’t need to worry about that side of things at all. A static wiki with no server-side editing would be fairly limited in utility. IkiWiki offers web-side editing via CGI. That might be one reason few people have bothered implementing such a system.
I’ve been thinking that using git as the backend that triggers rebuilds of the static wiki might be a working solution, at least for some kind of an audience.
That’s true. For https://ikiwiki.info, IkiWiki’s homepage, you can actually do that. Not only that, but that site is actually the
docsub-directory in IkiWiki’s actual source code repository, and they have untrusted git push set up for the site… the git hooks prevent you from committing outside ofdoc. But I’ve still always thought this was brave or foolish.Twenty years ago everybody wrote his own wiki like everybody writes his own static website generator now.
Today a wiki is rarely a standalone thing. It is integrated in larger products: Reddit, GitLab, etc.
Trying to get my workflow containerised so this is very cool. Thanks!
Great, now you have one more system to maintain.
In my opinion, quite the opposite. I’ll give a concrete example:
I had my own setup for experimenting with the Nim language, including the tool chain, editors, shell configuration, etc. I had to maintain this for two different systems (macOS and Linux), including different shell semantics, package managers, binary cross compilation and testing. Now I only have to maintain a single container which I can use in both environments. With the added benefit of immutability (ie changes to my “real” system don’t interfere with my sandbox).