I really like FeatherWiki as a lighter alternative to TiddlyWiki, it has fewer features but all the important ones are there.

I also need to mention thât the fossil scm has an integrated wiki, stores everything in a sqlite database (it's made by the same people) and is also very lightweight

I did the same search some six years ago for our company and ended up with MediaWiki. We had two requirements: ACL and Ease of Use for non-technical people.

Both of the above are missing in the plain MediaWiki but extensions helped out. There were few different ACL extensions and I can't remember which one I picked. Ultimately now we have the secret access controlled side of the wiki and the internal "public" side where everyone can access.

VisualEditor was a key extension. It's a rich text editor with minimal fuzz for MediaWiki. Users never have to deal with the MediaWiki markup which is a must for non-technical users.

Xwiki is missing.

For me after a similar search it is the current winner. Even though it has it'd downsides.

Pro:

• It is well tested in a enterprise enviromentand mighty

• It has all the features I personally found important for a company wiki, e.g. approval, versioning, templates, collaboration, integration api,etc.

• It is fairly easy to extend it yourself

• It is easy to host subwikis within the same installation with a self defined grade of independence - which is great for customer facing things,large projects with externals,etc.

• The development community is big and enterprise focus and release cycles are good. (Not like a certain .js) There is very little chance it will stall suddenly as the wiki has been adopted by a lot of large companies which seem to support it.

Contra:

• It is written in bloody Java

• (even though this sentence is redundant with the one above) It is a resource hog

• The look and feel is a bit outdated unless you customise it yourself. Then it is reasonably good.But there are basically no paid templates,etc.

• Paid support is only available through third parties it seems.

I use both dokuwik and, more recently, also wiki.JS.

Dokuwik is great and gets the job done but it's a piece of an old world. Maybe it's why I love it. Yes it's ugly and hard to theme. It's good old php all the way down.

Wiki.JS I love how consistent and easy it is to use and install. Has other drawbacks like require nodejs and store pages in a database, but uses markdown and feels modern and nice to use.

Pmwiki: own format, no access control, I would say it is a bit outdated.

DokuWiki

The table syntax at least is miles better [than MediaWiki]

For simple tables or for calculation tables, yes. It's relatively close to Markdown, even.

Unfortunately it does not play nicely with any sort of advanced syntax on table cells themselves, such as lists inside tables. For that, I prefer the MediaWiki syntax even if it's ugly (a DW plugin called exttab3 provides near 1:1 MW table syntax).

Some stuff like tags and moving pages have to be achieved via plugins. Seriously you can’t even rename a page?

IMO it's one of its strengths, and you can do most stuff with plugins. You can even render your pages as web slides with one plugin, and in fact I used to use DW as my "PowerPoint" for quickie presentations for over a decade.

All that said, there are DW "bundles" that incorporate some good and cool things together from the get-go. Anything that incorporates the Include, Indexmenu and Wrap plugins should be golden for getting started.

As for moving, I've asked around for a couple of years (more like 8) and seen how things have changed (or not), and it turns out it's half a consequence of documents being plain text files (there had to be some sort of disadvantage to that!). While it might (actually, is) possible to just move a file, there is no cheap, simple and fast way to also update all links that point to that page across the wiki, as those might be not normal links or even be dynamically generated by plugins. So most implementers are at the philosophical stage of "what even is a 'move'?" ATM.

I hear there are improvements with some plugins that advance some of the work, but I haven't tested myself. Don't need to, since I just use the Page Redirect plugin if I want to mark stuff as "moved".

Mutilates article titles. Makes everything lowercase and replaces non alphanumeric chars with underscores (or something else configurable)

Mutilates file names and mutilates article titles, separately.

The former is one of the PITAs in the design I feel. There are good, stable patches that allow uppercase filenames in the filesystem (as well as Unicode and even emojis) bu no core config option to enable them. The closest option is "safe filename encode" I think, which allows most accented letters, diacritics and stuff, but no punctuation signs, and still replaces into underscores.

I get the why (it's very useful for making sure article and section IDs are unique) but, like, still. It's 2026, I can name my second video card like the poop emoji and my system won't complain.

The latter is a configurable option actually. Just set the "use heading" preference to "always" and articles will always be titled the way the first heading available does it (so, technically, the same behaviour as MediaWiki).

Disclaimer

I've used MediaWiki for 6 years and DokuWiki for [*checks notes*] about 18.

Dokuwiki user here. Your cons are true, but compared to the cons of other ones, they are all solvable. The concern with a plug-in being required to do something is silly. It's open source and the plugin system is limitless. If it's ugly, make a theme. I've never had a problem with article titles being mutilated, but then again, I treat the file name (e.g. the url of the page) separate from the root header as you're supposed to.

Considering your comment about search being awful in another wiki, it's pretty good in Dokuwiki.

Considering how much you care about plain text, you should probably discount the con about file names as I'm pretty sure that's part of why Dokuwiki does what it does. It's an actual text file sitting in a directory that matches the path.

For what it's worth, I admire Obsidian. If it's a personal project with no intent to share, that's what I'd use. For business or public hosting, I'd use (and do use, at my company) Dokuwiki.

Have you tried

Outline?

I recently set it up and I'm very impressed.

Here are a few more:

logseq

Its an outliner, a colleague of mine basically lives in that thing.

silverbullet

It's almost perfect for me but the browser based editing made it unusable because there is no way to unmap Ctrl + W in a browser and I can't live without my Vim bindings.

QOwnNotes

This is the solution for normal people who don't spend n+1 hours tweaking their editor configuration.

Org-Roam

For people who do spend n+1 hours tweaking their emacs configuration.

I split my wiki-hopes and wishes into memos: https://github.com/usememos/memos

And hedgedoc: https://github.com/hedgedoc/hedgedoc

I've used mediawiki and I hated maintaining it. Absolutely do not recommend other than as a last resort.

I have found gitit easy to install and use though not all that featureful. It uses git as a backing store and there is an apt package for it (apt install gitit).

I used to put all my setup & config notes into tiddlywiki, and to some point I still update them, but it's become difficult for others to update and maintain when I share them as you need a browser addin to be able to save updates properly.

The formatting is similar to markdown, but just a little different to make copying the original source that way too... but... I'd still consider it, esp. once you've really played with it and found all the things it's capable of.

For work, we use Bookstack, you can use the api to export pages as markdown as a quasi-backup. At home, I have been using Jotty. It saves as markdown, organizes with folders, and has a decent mobile interface for when you're on the go. I just use syncthing to sync the data directory (markdown files in folders) to my backup storage

tiddlywiki has one of the most insane search engines from this list. They have a whole filters syntax that can express pretty much anything imaginable, no? I went back to TW from Obsidian because I was tired from Obsidian's trivial search functionality.