DokuWiki replaces the part of Notion and Confluence Cloud that stores and serves written pages, and it does that job well on a flat file store with no database. It does not replace simultaneous multi cursor editing, database views with filters and rollups, native comment threads with mentions, or first party mobile apps, and three of those gaps have no plugin that closes them properly. Everything else you want back arrives as a community plugin that you then patch, test and carry across every future upgrade yourself. If your team's daily work happens inside a shared page during a call, or inside a filtered board view, stay on your paid plan.
TL;DR by reader profile
- Solo consultant with a reference library (one writer, roughly 400 pages of notes and client docs): switch, because you never hit the locking model, and the full text index plus namespace ACLs cover everything you were paying a seat for.
- Five person engineering team that already lives in pull requests (backend squad, docs reviewed alongside code): switch, because plain text pages in a versioned directory match how you already work, and you can accept the editor being one person at a time.
- Twelve person marketing or ops team running trackers in Notion databases (content calendar, campaign status, filtered by owner and date): stay, because the struct plugin gives you typed fields and aggregation, not the relations, rollups and multiple saved views your calendar depends on.
- Distributed team that co writes in one page during a video call (a weekly planning doc touched by six people at once): stay, because DokuWiki takes an exclusive page lock and the second editor is told to wait or fork the content.
- Regulated company with an SSO mandate and joiner and leaver automation (60 staff, identity managed in Entra ID or Okta): stay unless you accept manual account lifecycle, because OAuth login is a community plugin and SCIM provisioning has no DokuWiki equivalent at all.
- Association, school or club with a small budget and mostly stable reference content (handbooks, procedures, meeting minutes): switch, because your content is exactly the shape DokuWiki was built for and your collaboration is asynchronous anyway.
The real tradeoff: you exchange a per seat bill and a vendor's feature roadmap for zero licence cost and a permanent maintenance duty on every plugin that stands in for a feature you used to rent.
Table of contents
- Can two people edit the same DokuWiki page at the same time?
- Is there a real WYSIWYG editor for DokuWiki, and what does it cost you in markup?
- What replaces Notion database views, relations and rollups in DokuWiki?
- How granular are DokuWiki ACLs next to Confluence page restrictions?
- Are there official DokuWiki mobile apps, and what do you actually use on a phone?
- Can DokuWiki do SSO, and what happens to SCIM provisioning?
- Where do comment threads, mentions and notifications end up?
- Which paid features DokuWiki genuinely beats, and why that still matters
Can two people edit the same DokuWiki page at the same time?
No. DokuWiki takes an exclusive lock on a page the moment you open the editor, and the second person is refused entry until that lock expires or the first person saves. There is no operational transformation layer, no CRDT, no shared cursors. This is the single largest behavioural difference from Notion and Confluence Cloud, and no plugin in the repository fixes it, because the storage model writes one whole text file per page.
The lock timeout is 15 minutes by default: the locktime setting in conf/local.php holds 900 seconds, and the lock file sits in data/locks/ named after the page ID.
The lock refreshes while you type: DokuWiki sends a keepalive from the edit form, so a colleague reading the "is currently being edited" message has no reliable estimate of when the page frees up.
Draft recovery is per user, not shared: unsaved text lands in data/cache/ as a draft tied to your session, so a crashed browser loses nothing, but nobody else sees your work in progress.
Section editing is the real workaround: DokuWiki locks per page, so splitting a long document into several pages under one namespace lets two people work in parallel on adjacent content.
The Edittable and Wrap plugins do not change this: they alter markup, not concurrency, and both still require the page level lock.
Teams that treat the wiki as an asynchronous record barely notice. Teams that open one planning page during a stand up and expect six people to type into it will hit the wall on day one.
Is there a real WYSIWYG editor for DokuWiki, and what does it cost you in markup?
Sort of. The stock editor is a plain textarea with a button toolbar, and the markup is DokuWiki syntax, not Markdown: headings are ====== Title ======, bold is **bold**, italic is //italic//. A true WYSIWYG surface exists as the community plugin ckgedit, which drops a CKEditor instance over that textarea. It works, and it is the reason most former Confluence users can be onboarded at all, but the conversion runs both ways and the return trip is where you pay.
| Editing option | What you get | What it costs you |
|---|---|---|
| Stock toolbar editor | Raw syntax, section edit links, zero conversion risk | Every writer learns a markup dialect that transfers nowhere else |
ckgedit plugin |
Rich text buttons, table handling, drag and drop of images | Round tripping can rewrite or strip syntax from other plugins, so complex pages need a raw pass afterwards |
| Markdown syntax plugins | Familiar # and - for developers |
Two dialects now coexist in one wiki, and search or find and replace has to cover both |
| Paste from Notion or Confluence | Fastest way to move a single page | Nested toggles, callouts and column layouts arrive as flattened paragraphs |
Two practical thresholds matter. First, any page carrying plugin calls such as {{page>...}} or struct fields deserves editing in raw mode only. Second, decide before rollout, because mixing editors across 300 pages leaves you with inconsistent whitespace and heading levels that nobody wants to normalise later.
Notion and Confluence give you one editor with one behaviour. DokuWiki gives you two, and you own the seam between them.
What replaces Notion database views, relations and rollups in DokuWiki?
The struct plugin, and it gets you about two thirds of the way. It attaches typed fields to pages through named schemas, stores them in SQLite via the sqlite plugin dependency, and renders aggregations with syntax such as {{struct table>projects}}. The older data plugin does something similar with ---- dataentry ---- blocks. Both are real tools. Neither is a database product.
Typed fields work properly: text, date, decimal, dropdown, user and page reference types all validate on save, so a status column stays a controlled vocabulary rather than free text.
Relations exist, in one direction only: the Page and Lookup field types point one page at another, and you can list what points back, but there is no rollup that sums or counts a related set into a parent field the way a Notion rollup does.
Views are markup, not saved objects: each filtered list is a wiki page containing an aggregation block, so changing a filter means editing a page. Nobody gets a personal view, and there is no per user sort state.
Board, calendar and timeline layouts are not included: struct renders tables and lists. If your team plans in a kanban column or a month grid, that presentation layer is missing, and dragging a card between columns does not exist.
Forms need a second plugin: bureaucracy builds the entry form that creates a page from a template, so a simple request tracker is a two plugin arrangement before you write any content.
Reference tables migrate cleanly. Anything your team actually manipulates as a board does not.
How granular are DokuWiki ACLs next to Confluence page restrictions?
Granular enough on the read and write axis, and clumsy on the organisational axis. DokuWiki ships an ACL manager in the admin area that writes plain rules to conf/acl.auth.php. Every rule maps a page or namespace to a user or a group and one of six permission levels: none (0), read (1), edit (2), create (4), upload (8) and delete (16). The most specific matching rule wins, and a user rule overrides a group rule.
Namespaces carry the model, not pages: you can write a rule for a single page, but the design assumes hr:* and hr:salaries style trees, so your permission scheme has to be encoded in your page naming before you migrate.
Only admins can change access: in Confluence any editor restricts their own page from the page menu. In DokuWiki that self service does not exist, so every access request becomes a ticket for whoever holds the admin account.
Moving a page moves its permissions: renaming hr:draft:review into a public namespace silently changes who can read it, which makes the move plugin a permissions tool as much as a housekeeping one.
Media inherits from the namespace it sits in: an image uploaded into a restricted namespace stays restricted, but the same file linked from a public page is served from its original path, so upload location decides exposure.
Read denial is total: a page you cannot read does not appear in search results, in the index, or in recent changes, with no "restricted content exists here" hint.
Three groups and a clean tree work well. Forty ad hoc exceptions do not.
Are there official DokuWiki mobile apps, and what do you actually use on a phone?
There are none. DokuWiki has no first party iOS or Android client, and it never has. What you get instead is a responsive default template that reflows to a phone screen, plus a remote API that third party clients can talk to. For reading, this is fine. For the workflows people actually do on a phone, capturing a note in a lift or clearing comments on a commute, it is a visible downgrade from a paid Notion or Confluence seat.
The browser is the client: the bundled template collapses the sidebar and sizes text sensibly, and templates such as bootstrap3 or mikio improve it further, but you are still typing wiki syntax into a textarea with a phone keyboard.
There is no offline mode: every page view is a request to your server. Lose signal on a train and the wiki is gone, where the Confluence and Notion apps keep recently opened pages cached locally.
There are no push notifications: DokuWiki's change alerts arrive by email subscription, so a phone gets them in a mail app, not as a badge on a wiki icon.
Third party clients exist but depend on the API: you must enable the remote option in conf/local.php, and optionally restrict it with remoteuser, before any external app can authenticate and post.
Photo capture is a file upload, not an inline action: the media manager accepts a camera file through the standard browser picker, then you paste the resulting {{:image.jpg}} syntax by hand.
Add the site to your home screen and accept it is a website. Anyone expecting parity with an app store client will be disappointed.
Can DokuWiki do SSO, and what happens to SCIM provisioning?
Single sign on: yes, through plugins or a proxy. Automated provisioning: no, and there is no equivalent to build on. This is the pairing that decides the question for most companies with an identity team, because the login half looks solved in a demo and the lifecycle half only hurts three months later when a leaver still has an account.
Directory authentication is the mature path: the bundled authad and authldap backends bind to Active Directory or LDAP, read group membership at login, and feed those groups straight into your ACL rules, so disabling an account in the directory blocks the next sign in.
OAuth and OpenID Connect arrive as plugins: the community oauth plugin plus a per provider service plugin covers Google, GitHub, Keycloak and generic OIDC endpoints, and it creates the local user record on first successful login.
SAML is usually solved outside DokuWiki: put an authenticating reverse proxy such as Authelia, Authentik or oauth2-proxy in front, then let DokuWiki trust the forwarded user header, which keeps the wiki ignorant of the protocol entirely.
SCIM does not exist here: no endpoint, no plugin, no group push. Joiners, leavers and group changes are either mirrored by your LDAP backend or performed by hand in the user manager.
Local accounts linger by default: the plain backend keeps entries in conf/users.auth.php until an admin removes them, and an active session survives until the cookie expires, so a deprovisioned employee is not necessarily locked out that minute.
If your compliance evidence includes automated deprovisioning reports, DokuWiki cannot produce them.
Where do comment threads, mentions and notifications end up?
Split across three mechanisms, none of them native to a page. DokuWiki has no comment system at all in the core. What it has is a subscription engine for change notifications, and a community plugin that bolts a comment box onto the bottom of pages. Inline comments anchored to a selected sentence, the feature Confluence reviewers live in, have no equivalent anywhere in the ecosystem.
Comments come from the discussion plugin: it renders a form under the page, supports replies one level deep, and offers moderation so posts wait for approval. Threads are per page, never per paragraph.
Comment data lives outside the page file: posts are stored in the metadata directory alongside the page, not inside the .txt source, so a page export carries the content and leaves the conversation behind.
There is no resolve workflow: a Confluence thread can be marked resolved and collapsed. Here a handled comment stays visible until someone deletes it, which pushes teams back to email or chat for review cycles.
Mentions do not notify anyone: typing a colleague's name creates text. The core subscription system is the only delivery path, and it is opt in per user.
Subscriptions are per page or per namespace, in three modes: every change, digest, or list. Digest and list batches are dispatched by lib/exe/taskrunner.php, which fires on ordinary page requests, so a quiet wiki delivers its summaries late.
The practical result: your review conversations move to Slack, Teams or email, and the wiki keeps only the outcome.
Which paid features DokuWiki genuinely beats, and why that still matters
Not every comparison runs one way. On four points DokuWiki is not merely cheaper, it is structurally better than what a hosted plan can offer, and those points are exactly why teams tolerate the gaps in the previous sections.
| Capability | What DokuWiki does | Why it matters |
|---|---|---|
| Content storage | Every page is a UTF-8 file at data/pages/<namespace>/<page>.txt
|
You can grep -r, script bulk edits, or put the tree in Git with no export step and no API rate limit |
| Revision history | Old versions are gzipped into data/attic with a Unix timestamp in the filename |
History survives independently of the application, so a broken install still leaves readable text |
| Backup and restore | Copy data/, conf/ and lib/plugins/ with rsync |
A full restore is a directory copy onto a fresh install, with no database dump, no schema migration, no vendor ticket |
| User count | Accounts and page count carry no licence cost | Adding a contractor for two weeks is a line in a file, not a change to your billing tier |
Longevity is the underrated one: DokuWiki has shipped on the same flat file model for years, and syntax written a decade ago still renders. Hosted editors change their block model on their own schedule, and your archive changes with it.
The absence of a database is the second: no PostgreSQL to patch, no connection pool to tune, no migration window. On a small server, the runtime is PHP and a filesystem.
If your content is meant to outlive the tool holding it, this column of the ledger carries real weight.
Top comments (0)