Experience Reports and/or Suggestions: Managing Files and Documentation with a Wiki and NextCloud

Hi everyone,

(Sorry, this became somewhat of a "long read". This article was posted in both the NextCloud and XWiki forums, as it relates to both.)

Surely I'm not the only one trying to solve this - I'd like to get first-hand reports / feedback on how you're doing this, so please share your experiences!

Please also provide tips and/or corrections if I got something wrong below or if I'm missing something obvious, which is all well possible. Obviously, your way to solve this is not neccessarily tied to a combination of XWiki and NextCloud, so please you might also share which software or solutions you're using to keep your documentation organized.

Thanks in advance! :)

As a small company, our team has to manage a bunch of files and documents like text documents, spreadsheets and presentation files.

We started using NextCloud, where we also manage calendars and address books, together with the Collabora CODE (a LibreOffice OnLine / LOOL distribution) collaborative online office editor for our mainly - but not exclusively - OpenDocument (i.e. LibreOffice) based office files. So you can edit those office files from your browser just fine by a simple mouse click and share them with all colleagues, or publicly using a public share link - readonly or read-write, at your option, and also optionally password protected.

NextCloud replaced a pure WebDAV drive we used before to share files and documents in our team.

However, for much of our documentation it would actually be better / more appropriate to edit it in a Wiki. You can organize content in a more fine-grained way, and much more easily add seamless cross-references between different topics.

Therefore, at a later point we chose XWiki (comparable to the popular Confluence) as our wiki system and are quite happy with it.

However we're fighting with "media disruption" since then and are still looking for the best approach to solve this. "Media disruption" means that it's not always clear if a specific information someone's looking for is contained in a wiki page or in a document, so it's not totally clear in which system to start looking for it. Also if new content is to be created, the question is whether to put it into a wiki page or into an office document.

Both systems have their pros and their cons:

  • The wiki allows the above-mentioned more fine-grained content organization and more seamless cross-links between different parts of the documentation and/or different topics.

  • Creating and editing complex tables / spreadsheat documents is much easier with NextCloud and Collabora CODE than with Xwiki itself.

  • In case of really complex changes, or if you need to or want to work offline, one can just use the NextCloud sync client to locally edit the office files using a full-blown desktop office suite (LibreOffice or MS Office) and sync the changes later.

  • Managing larger amounts of "files", be it image files, exports in specific XML formats or whatever, is a "home game" for NextCloud, but no neccessarily so for a wiki system.

  • Sharing documents and providing access for foreign users without an account in our systems is easier and more flexible with NextCloud, allowing the creation of anonymous document or folder sharing links with optional edit permissions, optional password protection and optionally limited lifetime with one or two mouse clicks.

  • (Re)Organizing content in NextCloud just works intuitively by "Drag and Drop", while it's slightly more complicated in XWiki.

  • Collaborative real-time editing (several people working on a single document at the same time) is only experimental in XWiki and not yet ready for production use, but works just fine in NextCloud with Collabora CODE.

  • Unfortunately, NextCloud does not allow direct links to office documents which directly open them in view or edit mode, but require a NextCloud user account to function.

  • A bunch of our documentation exists in specific formats for "historical reasons" at the moment.

So we're struggling how to deal with this best. We try to keep the documentation structure in NextCloud and XWiki similar by convention, and also prepared guidelines what kind of information and documents to create or put where.

But still the integration is far from seamless and far from satisfactory. Only one example is that the search features in either system obviously will not point out relevant information in the other one.

So, how to improve this?

  • XWiki and NextCloud both have OnlyOffice online office integration. I haven't tried this yet, but it sounds similar to Collabora CODE. Contrary to CODE however, OnlyOffice internally is based on the OfficeOpen XML data model (i.e. MS Office formats) while CODE internally is LibreOffice, so OpenDocument based, which calls for format conversion problems. Also, I've read that the NextCloud OnlyOffice integration is more limited concerning document sharing / share link options.

    • So on the pro side, this might enable us to collaboratively edit office documents directly in XWiki, stored as wiki page attachments.

    • On the con side:
      • It will neither simplify sharing those documents from Xwiki,
      • nor - at least by itself - allow seamless offline document editing using desktop office suites.
      • We would have to administrate an additional server application, or - if it's really a full-featured replacement for Collabora CODE also in NextCloud - another server.
      • XWikis own Office Server used to generate office file previews is based on LibreOffice, so will work quite well with OpenDocument files, but most likely incur the unavoidable conversion errors with OnlyOffice-created OfficeOpen XML document files.
      • Even Office documents will then also be spread between XWiki and NextCloud if we cannot get rid of Office documents in NextCloud completely and move all of them to XWiki.

  • XWiki provides a File Manager application.
    • On the pro side, we could use it to try to completely replace NextCloud files as a file sharing solution with XWiki.

    • On the con side:
      • Files stored as page attachments in Xwiki do not automatically appear in the FileManager extension and the other way around - so the "media disruption" somehow still would be there, but moved into XWiki itself... ;) You cannot organize the normal wiki contents and attachments using the File Manager application. Also it still would not always be clear if you'd have to look for information in some wiki page which then has the file as an attachment, or in the File Manager application. To alleviate this, at least linking/referencing files would be easier, and everything should be caught by XWikis search feature.
      • The XWiki File Manager web interface feels and looks somewhat clumsy if you're used to NextCloud's.
      • The content sharing limitations discussed above still hold.
      • XWiki by default does not allow access to FileManager and attachments with desktop applications. (See below for a discussion of the separate XWiki WebDAV server extension.)
      • In the same vein, it does not support local offline mirrors of all files out-of-the-box.
      • It's not clear to me how well XWiki's File Manager extension scales in case of many files - I'll ask this in a separate question in the XWiki forum, though.

  • XWiki and WebDAV - XWiki aktually has a WebDAV extension which exposes its contents (like spaces, pages and attachments) via the WebDAV protocol, which can then be access more or less easily using desktop applications.
    • On the pro side, this finally allows editing office files using a desktop office suite also with XWiki.

    • On the con side:
      • The WebDAV extension is not officially supported in any way, and development seems to have stagnated / stalled. It's also at least partially based on aging infrastructure components like Apache Jackrabbit 1.4. It's not clear to me how "future proof" this extension will be if I base my documentation concept on it. I'm also not sure if using aging components like Jackrabbit 1.4 may have security implications (e.g. software vulnerabilities fixed only in more recent releases).
      • Attachments and files from the FileManager application are both exposed via WebDAV, but also here the File Manager application provides it's own separate folder hierarchy, so files managed there are separated from files stored as attachments.
      • The folders which are exposed are sometimes somewhat inconvenient. The specific "attachments" folder for example only shows a flat list of structured space names, instead of a hierarchical representation. The "spaces" folder which exposes the spaces hierarchy with all contents and also all attachments provides the expected hierarchical presentation, but also exposes all XWiki pages as two text files (one pure text file and one XML file). That's a better representation where we could also put all of our files next to the actual wiki pages, but it's a bit convoluted as it also displays XWikis "WebHome" pages which are an implementation detail of how nested pages/spaces are implemented and which normally is not explicitly presented to the wiki user. Also the same information is exposed via different paths, adding to this impression.
      • WebDAV support especially in Windows is flaky, and there is no native offline sync solution. We could test and try to use a separate tool as Cyberduck (https://cyberduck.io/), but a specialized sync tool like the NextCloud sync client is easier to set up.

  • NextCloud allows to mount / access external storage, including WebDAV. We could provide access to XWiki's contents via the NextCloud web interface and maybe even sync client this way.
    • On the pro side,
      • all XWiki attachment files could then probably be found using nextcloud.
      • and probably, XWiki content could also be (re)organized using the NextCloud interface.

    • On the con side,
      • this also does not solve the issue of documents being hidden in different organisation hierarchies.
      • The XWiki WebDAV server extension is not supported and not too actively maintained, as stated above.
      • The content struture exposed via WebDAV is redundant and somewhat confusing in several aspects, especially to a "normal" user.
      • It's not clear to me how stable and reliable XWiki reacts if I'm moving lots of stuff around via WebDAV.

So long story short, everything I've tried or thought about so far is far from being perfect.

What tools or solutions do you use to solve your documentation problems, and with which setup did you end up with?

Thanks for any insights in advance - and maybe my thoughts provided some insight to someone else. :)




So apparently onone besides @SolarDesalination and me has to deal with both file and wiki based documentation. :wink:

Maybe it didn’t get clear from my post.

My question does not really focus on concrete software products (though in the end of course it’s also relevant what actually can be done using NextCloud and XWiki), but more a general question - how do you deal with the “media disruption” between Wiki-like tools, be it Confluence, MediaWiki, XWiki or whatever, and file-based tools like NextCloud?

Acutally, to my surprise, the CEO from XWiki SAS also responded in detail to this post’s copy which I posted to the XWiki user forum:

In the end it mainly explores ideas how a Wiki and NextCloud could more seamlessly be integrated, which in general might help NextCloud to integrate better with other software stacks and solutions. This would be very interesting and desirable from my point of view.

1 Like

Following with great interest though my work has my preoccupied with other things at the moment.

Ok, also @just has to fight with this… :slight_smile:

I just replied to Ludovics in-depth post in the XWiki forum:

Looks as if better integration also needs additional features on the Nextcloud side, but at least some of the corresponding feature requests already exist, but there’s no visible activity on them…

Is really noone here who’s using a Wiki and Nextcloud and can share her/his solutions, how she/he deals with having two systems?

We are facing the same issue. We just upgraded our server and moved to Nextcloud. We are an NGO (non-profit) with limited staff. In the upgrade we are moving functions in other software to plugins on Nextcloud. But the wiki issue remains. We want to reduce the number of applications we use to reduce work load in maintaining them. As noted, document storage (Nextcloud) has it advantages and the wiki has it’s advantages. We have been using JSP wiki.

On the problem of where to find information (Media disruption), that occurs even if you use Nextcloud. Which directory is the document I am looking for in? One rule we have if you look in the wrong place put a pointer there to the correct location ( a text file named with the proper location). with JSP wiki we can easily put in public links to the Nextcloud on a page.

I’m using


to do this, much more convenient than text files with a link you have to copy!

However you should wait for the next released version of the README.md app, as v 1.0.4 has layout-related bugs which mess up the Nextcloud search feature.

I’m currently working with a snapshot version from trunk which has most issues fixed which I reported, and it works quite well.

Version 1.1.0 which includes important fixes is out: