Hi everyone!
I’ve joined XWiki SAS in October 2021 with my main task being to work on the XWiki open source project. I somehow missed introducing myself here in the forum even though I’ve already written 159 posts and created 45 topics here so let me take this occasion to a) briefly introduce myself and b) provide some impressions after one year of being part of XWiki.
Introduction
I think it was sometime around 2004 when I discovered wiki software and around 2007 when I started using DokuWiki for my personal website. I was attracted by the flexibility it provided, having extensions like the blog plugin that lets you turn a part of the wiki into a blog (a bit similar to the Blog Application in XWiki). I started contributing to DokuWiki in 2008 after meeting the developers of DokuWiki at FrOSCon 2008. In the following years, I studied informatics and spent quite some working on DokuWiki and extensions. In 2016, I represented DokuWiki at FOSDEM at a shared stand with XWiki (and Tiki) and Ludovic mentioned to me that XWiki is always looking for PhD developers as I had started a PhD two years ago. Fast forward to 2021, I had finished my PhD and was now looking for a new job. As it happens in so many cases, life happened and my time for open source contributions got rarer over the years. Therefore, contributing to open source during my job seemed like a great option to basically turn my hobby into a job. I remembered XWiki, applied and, well, here I am. 
Impressions coming from DokuWiki
Coming from DokuWiki, a relatively small codebase, XWiki is just huge. There seem to be countless features (like annotations, charts, formulas, …). Want to have some extra JavaScript or CSS on page, some part of the page dynamic according to some URL parameter? No problem, that’s all supported if you have the rights. In DokuWiki, the set of features is quite limited but there are countless extensions that provide extra features, many of them are provided by developers who seldomly (or never) contribute to DokuWiki itself.
What I really like about DokuWiki is its simplicity:
- Installation is easy, you just need some webspace that supports PHP (not even a database, the contents are stored as plain text files).
- Backups are easy - just take a copy of the files. You can even easily access the contents in that backup, every wiki page is a file with nothing but it’s content, even revisions are simple full copies of the page with a timestamp in the filename and gzip-compression (compression is configurable).
- The bundled features are easy to understand.
- It is relatively straightforward to create a theme or plugin (extension) and there are many community-contributed themes and plugins.
In contrast, XWiki is quite complex. It’s not just much more difficult to run (where you also need to make sure to choose the right cache size settings etc. according to the available memory), also backups are much more complicated. The mixture of code and data makes it complicated to even identify which documents would be needed for a full backup of the contents, and even when you go on the layer below you need to take care of backing up the database and the files which contain the Solr database where you need to take care that you get a true snapshot (and not just copy one file after another). And when writing code for XWiki, there is a lot of stuff to take care of - different reference formats, contexts, proper escaping for the current syntax, … which makes writing correct and safe code quite a challange.
The great flexibility that XWiki offers unfortunately also results in quite a lot of potential for security issues, in particular with the reliance on who is the last author of some content for security checks as in many cases content from different sources is mixed. In DokuWiki, this is much simpler - all extensions are written in PHP, which gives you full access but there is no way to execute PHP from wiki content, the author of the wiki content doesn’t play any role. Only admins are allowed to install extensions. There is also no way to inject arbitrary HTML, JavaScript or CSS from wiki content, there is not even support for custom parameters on elements. To be fully precise, there is a feature to embed PHP and HTML in wiki content, but it is disabled by default, enabling it is strongly discouraged and the feature has been removed recently (hasn’t been released yet). Admins can add custom CSS or override translations (which are also defined in PHP files, not in wiki pages) by creating certain files in the filesystem (there is also an extension to create and edit them from the admin UI).
Of course, XWiki also offers a lot of features that are hard to realize with just plain text files. DokuWiki has extensions like data and the more recent struct that allow adding structured data which is stored in an SQLite database but this is not nearly as integrated and powerful as XWiki’s structured data features (at least when I checked last time, e.g., there was no support for versioning in struct). The ability to easily create custom applications in XWiki is definitely a great feature, it just comes at a price.
Another feature that just doesn’t exist in DokuWiki is the support for pages in different syntaxes. DokuWiki’s parser, which is based on a sophisticated combination of regular expressions, allows extensions to define arbitrary syntax, though, which is enough to implement almost full Markdown support on top of DokuWiki’s own syntax.
Inspirations
In the following I want to mention a few things where I think XWiki could take an inspiration from DokuWiki:
Better wiki syntax editor
DokuWiki doesn’t have any bundled WYSIWYG editor. However, there are still features like a link or image insertion dialog, features I’m missing in XWiki’s wiki syntax editors. Also, when pressing enter in a list, the list is continued and space/backspace indent/outdent the list. I think a wiki syntax editor with more advanced features could be a nice addition for XWiki power users/developers.
Make it easier to start developing extensions
DokuWiki has a plugin wizard where you can provide the basic information what kind of plugin you want to develop, which events you want to handle, if you want translations, etc. You can unzip the output in your installation, edit the files to add the code you need, and test the plugin live in your wiki (you can of course also write unit tests, the wizard allows generating them). Publishing a plugin in the repository is as easy as creating a wiki page, just provide a URL to a zip file (can be the one auto-generated on GitHub) and you’re done.
In contrast to this, the whole process around XWiki extensions seems much more involved. Maybe such a wizard could be an inspiration for XWiki? More recently, DokuWiki also got a dev plugin that allows adding additional components, tests etc. later. I could imagine commands like adding a page test for a certain document to be quite handy for XWiki.
Form builder
As a developer, one thing that I really like about DokuWiki’s extension APIs is the form builder class. Basically, whenever some HTML form shall be displayed in DokuWiki (think user registration, login, page editing, edit conflict) an instance of a form class is created to which the different inputs are added (a bit similar to XDOM in XWiki). This has two advantages:
- All forms use the same HTML structure with labels, escaping etc. properly handled.
- Before a form is printed to HTML, an event is triggered with the form as data. This allows plugins to modify the form (e.g., add additional inputs, buttons, …, but also remove or modify existing elements).
This makes DokuWiki incredibly flexible without requiring a lot of code. In contrast, XWiki’s UI extensions seem quite limited as they only allow inserting something, possibly with a defined priority. Of course, things can also get messy when several plugins modify the form but usually it works quite well. It probably doesn’t make any sense to change the existing UI-extension system, but maybe it can be an inspiration in case XWiki needs a new form API somewhere.
Cache system
DokuWiki has an on-disk cache system (there is no permanently running process). It is relatively simple, on every access it is checked if the cached resource is up-to-date (e.g., by comparing the modification time of the cached resized image to the original image file). Cache accesses usually also trigger events, so extensions can add additional conditions for deciding if the cache should be used. In XWiki, all caches are currently discarded when the instance is stopped, maybe for some more expensive things (like resized images), it could make sense to introduce a persistent cache?
CSS and JS bundling
In DokuWiki, all CSS and JavaScript files that are either in the core or in extensions are compressed, minified and served as one resource for CSS and one for JavaScript. The processed resources are also cached on the server. In contrast to that, XWiki includes a huge number of CSS and JavaScript files in every request. I know that many of them are only served on demand but I’m still wondering if it couldn’t make sense to bundle and cache a subset of them to reduce the number of requests. Unfortunately, I have no data to support that what DokuWiki is doing is still a good idea with modern web browsers.
Metadata rendering
In XWiki, every part of the code that needs some metadata from a document like all links to other documents or all headings for the toc traverses the XDOM to get them. In contrast to this, DokuWiki has a metadata renderer that creates a nested object/array structure (similar to JSON) that contains metadata like all links to other wiki pages or the table of contents. Code that wants to get them, e.g., for indexing, then doesn’t need to traverse the content but can read the metadata. Extensions that extend DokuWiki’s syntax (like macros in XWiki, but more flexible) can contribute their own metadata that can then, e.g., be indexed in the search index without needing to traverse the whole document again.
Running tests on several versions
What has been discussed for XWiki recently, to run tests of extensions on different versions of XWiki, exists in DokuWiki already since quite some time: Tests of extensions can easily be run with different DokuWiki and PHP versions (via GitHub actions usually since Travis stopped unlimited open source builds). Tests are also executed on pull requests but also just need a couple of minutes due to the much smaller feature set and the fact that there are no UI tests in DokuWiki.
Rights are all stored in one place and are simpler
DokuWiki has a single configuration file that stores the rights for the whole wiki. They can be edited from the admin configuration which gives a nice overview of all rights but of course requires admin rights for editing them. The rights system is also much simpler, they are just levels and not a composition of different rights. So for example, you cannot have edit right without view right. Of course, this is hard to scale if you have many different rights, but DokuWiki also offers options like placeholders for the current user such that you can say “in this space editing is forbidden but each user can edit a page whose name matches the username” with just two rules.
Conclusion
Overall, DokuWiki wins regarding simplicity while XWiki wins in terms of features.
If you have any questions or comments, please let me know! Also, if you think that any of the above-mentioned features could indeed be an inspiration for XWiki, feel free to create tickets in Jira and start working on them, I doubt I’ll find the time for any of them anytime soon.