Here we list a couple of starting configuration settings that we deem would make the wiki more production ready. The term config in this page usually refers to the configuration page itself, found under the admin panel. Documentation for specific configuration fields can typically be found in the Dokuwiki configuration page.

To explore the large Dokuwiki universe and support links, head on to the about page.

Set the following configuration fields, optimized for semi-private wikis:

• title
• tagline
• dmode: Preferably 02770 - restrict other access, with setgid
• fmode: Preferably 0660
• typography: None - disable smart quotes rendering as unicode
• dformat: %f (%e %B %Y) - fuzzy timestamps with readable date
• showuseras: User's full name - obscure logins
• sneaky_index: Enable - obscure restricted namespaces
• hidepages: ^:(playground|sidebar)
• useacl: Enable if wiki is semi-private (see the ACL section below)
• updatecheck: Enable - check security updates
• userewrite: .htaccess (indicates handling by the webserver, not just Apache)
  • See the following page for URL rewriting by nginx, specifically the @dokuwiki directive for try_files under the root location.
• useslash: Enable - prettify URLs

The favicon can be overridden by uploading :favicon.ico file to the Dokuwiki media root (preferably in multiples of 16x16px), while the logo can be overridden in the default template by uploading :logo.png within the same root namespace (preferably 50x50px).

The default Dokuwiki descriptions, e.g. the text above the page editor, are stored within the Dokuwiki directory, and can be edited by the webserver admin. The files are located in /inc/lang/[LOCALE]/[DESCRIPTION_FIELD].txt, as referenced by the following forum post.

Note that some descriptions are template-specific, e.g. the footer text of the default template is located at /lib/tpl/dokuwiki/tpl_footer.php.

Dokuwiki content has a similar hierarchy as that of a filesystem - pages (text files) reside in nested namespaces (directories). There are many ways to classify content, but note the following conflict between namespace classification strategies:

1. Empirical (property-based): Permissions (via ACL) can be granted on namespace-basis
2. Functional (topic-based): Natural grouping, i.e. by functional criteria or subject
3. Flat: Only meta-content (about the wiki and its administration) are given namespaces, e.g. Wikipedia

To incorporate both policies, the namespace system used in this wiki is as follows:

root
+-- [group]
    +-- [topic]
        +-- ...
            +-- [content]

• The top-level hierarchy is based on the group access permissions, to effectively demarcate public from private content. The hardcoded group topic is actually a public-facing alias for the public group, so that categories will not be confounded with the other groups.
• The second level is a nestable hierarchy of topics (grouped based on function), up to a recommended limit of two nesting layers, e.g. [group]:[topic]:[subtopic]:[content]
• Meta content, such as todo, start/description, sidebar, can be attached to the appropriate namespace.

To circumvent restrictions on strict hierarchical categorization, the tag plugin can be used to assign tags for common categories, such as type of record (e.g. meeting, thoughts), subject, meta-tags (e.g. important), organization, etc. A virtual namespace containing the associated tag can then be created to browse by tags.

Read the section on content organization above first, before implementing ACL rules.

The principle behind Dokuwiki's ACL is similar to Nginx's access permissions - the rule with greatest specificity (user > group; page > namespace > root namespace) are applied. The easiest way to understand these rules is to review the ACL example scenario in the documentation.

These rules can be edited under the Access Control List Management page in the admin panel. This also involves editing the groups each user belong to, under the User Manager page in the admin panel. Note that guests are part of the @ALL group, while registered users are by default automatically in the @user group.

A basic sidebar can be created with the following steps:

1. Ensure the sidebar config field is populated, e.g. mysidebar.
2. Create the corresponding mysidebar page in the root / namespaces and edit the page text. This text will be immediately reflected in the sidebar.

Multiple sidebar pages can exist, with each page resolving to closest sidebar page along the parent namespace path. For a quick and dirty sidebar, embed the entire sitemap in the sidebar page using the simplenavi plugin, i.e. **Sitemap** \\ {{simplenavi>}}.

More details on customizing the sidebar can be found in the FAQ.

Plugins allow easy extension of the base Dokuwiki installation to provide additional features or enhance user experience. Common plugins are primarily classified into syntax plugins that can be used in pages, and action plugins that supplement Dokuwiki functionality. Some useful plugins are listed below.

• admnote: For admonitions (e.g. info, warning, danger), given by syntax.
  • Source reviewed on 2021-06-07.
• flowcharts: For diagrams and flowcharts using Mermaid syntax.
  • Requires modifying entities by adding the /conf/entities.local.conf file.
  • Check out the live editor for examples.
• tag: For tagging pages. See the Content Organization section on a possible tag use case.
  • Requires the pagelist plugin for manual listing of pages.
• simplenavi: For automatic listing of all sitemap pages.
  • Consider the dir plugin as an alternative.
• bookmark: For inserting anchors for direct linking to content in page.
• folded: For inserting hidden sections, much better than the 'hidden' plugin.
• fastwiki: Probably the extension that streamlined my entire wiki editing experience.
• mathjax: For rendering LaTeX-styled math equations.

• imgpaste: Allows insertion of images via direct pasting into editor.
  • Image itself is automatically renamed and uploaded into a nested pasted namespace.
• move: For drop-and-drop page and namespace management in a tree view.
• autologoff: For automatic logging off functionality, especially when logging in from a public computer
  • This doesn't seem to work on older browsers, so be careful where you log in from
• upgrade: A relatively new entry, that allows the wiki to auto-update *and* prune deprecated files. A must-have.

• iframe: For loading iframes on the page.
  • While iframes are not inherently dangerous, untrusted code loaded by guests and other editors can be dangerous. Do not load this plugin in a multi-user wiki environment.

Dokuwiki can optionally be customized through the use of templates (although the default template is arguably the best in terms of plugin compatibility and content presentation). Some suggested templates to explore:

• Vector: MediaWiki look-and-feel.
• ReadTheDokus: Similar in presentation to ReadTheDocs.
  • Note that configuring /conf/meta.html and /conf/userall.css is required.
• Argon: Based on the Argon design system, with strong similarities to the Google Material design.
• Material: Based on the Google Material design.
• Bootstrap3: Uses Bootstrap library.
  • Recommended to install the companion bootswrapper and icons plugins for visuals.

The formatting of the templates can be manually overridden, using the styles specified below in increasing specificity:

• /lib/tpl/[TEMPLATE]/style.ini ⟶ /lib/tpl/[TEMPLATE]/css/*.less
• /conf/userstyle.css
• /conf/tpl/[TEMPLATE]/style.ini

The GeSHi syntax parsing definitions for the desired language can be found in /vendor/geshi/geshi/src/geshi/*.php. See Dokuwiki's provided list of code CSS overrides for examples. The CSS overrides for this wiki are documented here.

• The attic stores old revisions. To clean them, as well as abandoned pages and namespaces:
  • Delete revisions: /data/attic/[NAMESPACE]/[PAGE].[TIMESTAMP].txt.gz
  • Modify revisions list: /data/meta/[NAMESPACE].changes