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. :)
Regards,
Gunter
