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

Help / Discuss
1

Hi everyone,

(Sorry, this became somewhat of a "long read". This article was posted in both the XWiki and NextCloud 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

2

Interesting discussion! Some thoughts at random.

Yes, I think XWiki would benefit from integration of some “Excel” like JS framework for editing large tables. Something like https://jspreadsheets.com/. The closest right now is either the OnlyOffice extension or the Google Apps integrations I guess where you’ll edit your spreadsheet with external tools but the result is saved in XWiki and thus anyone can modify it from the wiki (single location for files).

I’d be curious to know what’s missing in XWiki on this aspect.

I’ve also identified this point. I created a jira somewhere to be able to generate a custom URL for a page that could be shared with users without an account on the xwiki instance and still allow them to edit content. Can’t find it right now :wink:

BTW have you checked out Cryptpad? CryptPad It’s a google drive competitor but with zero knowledge (everything is encrypted) and it’s awesome for sharing content. It’s done by XWiki SAS. In the future XWiki SAS wants to develop some bridges between XWiki and Cryptpad to make them exchange content in an easier way.

Actually we believe it should be production ready (or very very close) but we need more feedback. Would be great if you could try the latest version and tell us how it works.

You should try it, I tested it a few times and it worked very well for me and it’s very convenient. It’s especially great for organizations used to (MS) Office docs and it allows them to use a familiar editor. While at the same time allowing to transition to a wiki-based content management system.

Well XWiki has a share page feature and any user in the wiki can edit in realtime and collaboratively office docs attached to wiki pages :wink:

Do you mean sharing for users not having an account in the wiki? Couldn’t you integrate with LDAP or something so that everyone gets an account? Is the need for external users to the company?

At least you get to see them all in the attachment view but also in search.

Could be great to create some jiras for the file manager extension at Issues · xwikisas/application-filemanager · GitHub to tell XWiki SAS what could be improved specifically :slight_smile:

It should scale very well since:

  • XWiki stores attachments on the filesystem now
  • The File Manager app creates one page per file and XWiki scales very well with the number of pages (we know xwiki instances with several millions of pages without issues).

Yes that was true. The main reason was the one you mentioned later below, i.e. that WebDAV clients are flaky depending on the OS and it’s hard to get a good experience across the board. Now this extension is still not supported by the core xwiki dev team as a whole but there’s been recent work on it by Clemens (a core committer). See Commits · xwiki-contrib/webdav · GitHub

I don’t feel this is a problem since you can navigate by pages or by attachments and they both point to the same attachments in the end.

This could be easily fixed. BTW if you were interested in sponsoring the WebDAV extension, I’m sure XWiki SAS and Clemens would be happy to help on that.

Yes this could also be fixed easily.

Thanks for starting this discussion.

3

Looks pretty interesting and slick and would be a cool addition to XWiki actually, if it can be created and edited easily.

Still, there will be several cases where a full fledged online office solution has advantages. OnlyOffice is an already supported option, alternatively integration with Collabora CODE would be fine for users who chose this and cannot or do not want to switch / migrate and cannot or do not want to administrate and run both of them.

See:
https://jira.xwiki.org/browse/EXOIDEA-1

I tried it a while ago, and it did basically work, but I e.g. stumbled across Loading... and postponed further tests until this is resolved. I fear that problems like this will affect XWiki user acceptance in my team, especially if it cannot directly be attributed to some specific extension by a normal user - the general impression will just be that “XWiki doesn’t work”.

Well, the think is that we’re already using Collabora CODE, which is a direct competitor to OnlyOffice,
and so we’d have to add an additional service we need to administrate, setup and which my users have to learn, until we decide that we could ditch one of them again because the other can completely take over.

Another drawback of OnlyOffice is that its Community Edition does not support presentation files. And I only want to buy a license if I’m confident that it’s the right tool for us, just as I did with XWiki. :slight_smile:

I’m nevertheless curious to try OnlyOffice, but so far am lacking the time to try it.

We did integrate XWiki with our LDAP, but we also share documents - sometimes editable, sometimes not - with employees from other companies.

Mh? I’m a bit lost. :slight_smile:

That’s actually a bit difficult - I’m no UI gui and it’s a bit difficult for me to describe what’s actually missing from the XWIki FileManager UI. Possibly I’ll have to try it a bit more. I just know that NextCloud’s file management web UI feels much slicker and “straigt forward” to use at first glance.

Mh, however this sounds like quite a bit of overhead to me - for example, we have many hundred tiny icon image files, each of which is only a few hundred bytes in size. (Icon resources for our projects.) I’d imagine that XWiki then probably creates more management information in the database than the actual icon file actually contains as data. :slight_smile:

However, I’ll give it a shot and see how well FileManager deals with this use case.

Ah, good to hear.

Meanwhile, I tried to include XWiki as an “external storage” in NextCloud using WebDAV. The idea was to make XWiki attachments searchabel in NextCloud, even if it would still be in a separate folder hierarchy.

However, this only “sort of” works and bails out very often, but I’ve not yet had time to analyze it further so far.

Also the XWiki WebDAV server folder layout is pretty complex and actually redundant, with the same information accessible using different paths.

I’m lost again here - maybe I got something wrong concerning the way the File Manager extension works? I wasn’t able to see any pages or any attachments in the File Manager application. It had a totally separate folder hierarchy, independent of my XWiki pages / spaces.

So the only advantage of using the File Manager application would be that its contents would be covered by the XWiki search feature - I’d still have two separate documentation hierarchies, as I currently do with XWiki and NextCloud, and as a user looking for documentation concerning something you would have to manually look at the corresponding location in both hierarchies yourself if you do not know what words to search for…

I do not want to exclude to sponsor some XWiki development, however it’d be good to know how this is “usually” done at XWiki SAS and what it would cost and what I could expect in return. I still have a question open with your commercial support regarding this and assume they will get back to me soon with some feedback.

Maybe another interesting feature actually might by WebDAV client functionality in XWiki, possibly as a macro or something - then I might be able to display a list of files from the corresponding NextCloud folder within the XWiki page as clickable links… Tough that’s also not yet really though out till the end, I’ll continue to ponder this a bit…

Regards,

Gunter

4

This is a very interesting discussion. Thanks for bringing it up. Don’t hesitate to post the link to this response in the NextCloud forum. Hi to NextCloud devs ! We love what you do.

The first thought here is that the difficulties there are with office files, is a big reason why Wikis have been created. Office files tend to push user towards a system that is centered around the individual user versus the group and which does not allow to properly link information and also to categorize. The file format itself does not include the features that bring the documents together and the most tools that work with office files are trying to answer the need of editing, storing and sharing but not as much the need of categorizing it.

Wikis have been created trying to take the problem from a new standpoint, based on the fact that we have new technologies available like browsers, online editors, databases and so on. A wiki is an online system which allows anybody to edit documents and link them between each other. A key aspect of wikis is that it should allow to quickly go in edit mode, make a change and save.

Now the issue is that:

  • users still have a tremendous amount of office files and habits of working with them
  • office file editing is very rich and this is compelling when you are doing more advance things
  • offline editing seems more easy as you have offline tools and conflicts are not taken into account (which can work when document are more user centric instead of group centric)
  • integration between the wikis and office files and between wikis and office files management tools is lacking
  • office file management tools have been becoming more collaborative trying to answer some of the problems listed, however they have not solved all the issues and some of the issues will be very hard to solve as they are contradictory with features of these tools (for example: while having tons of editing features is nice, it goes in the way of fast & easy editing)

In the end there is a sort of competition between wikis and office files, and depending on the use case one if more appropriate then the other. It would of course be super interesting to improve the integrations between the tools.

So first it is important to choose the right tool for the task based on the objective, and then second see how to connect to tools if it makes sense to do it.

If the main use case is creating documents and sharing them one by one, I would tend to go for office tools.

If the main use case is documentation or procedures or management a set of knowledge and collaboratively edit it and organize it and then make it nicely browsable and accessible, I would clearly go towards a Wiki.

I’ve created XWiki because I believe we need new ways of collaborating and the office file not adapted to these new ways. New ways to organize the content and group it together are needed. Unfortunately standardization is very hard in this area and big players are still going the office file way (Microsoft & Google).

Now XWiki’s goal is to capture & organize information. It is not said that all editing tools and content should be in XWiki and organizing content that would be stored and editing in other tools make sense to the goal of XWiki. We have Office365 and Google Apps plugins allowing to display files from these tools, and doing with other tools and in particular NextCloud would be very interesting.

So now how to treat your particular use case and how could it be possible to solve your problems and as well make the tools work together. I’d like to point out that I would love if we could make the XWiki & NextCloud tools work better together. If there are any companies that are ready to sponsor this work it would be great and we would be happy to do this in collaboration with NextCloud which I believe would be necessary because our initial studies of integrations show that there might be missing APIs and functionalities for such integrations to work well.

Let’s look at your issues and problems and how these could be solved:

Indeed. Office editors are more advanced for spreasheets. This could be improved indeed in XWiki.
Now in XWiki you can also create databases using App Within Minutes which can give more structured content which can be very useful for documentation.

XWiki also have OnlyOffice integration to edit office files, including XLS. We chose OnlyOffice because we are also using this technology for CryptPad, because it is full Javascript and allows us to encrypt the collaboration which would have been impossible with Collabora CODE. It’s true that Collabora has more office support as it’s built on top of LibreOffice. Integration would be possible in order to have a choice. It’s significant work however which is why it hasn’t been done yet.

Indeed, offline Wikis would be nice, but given the more active collaboration on Wikis it’s a significant problem. We can’t expect that the majority of editing will be only one user at a time, which is what offline support of office files in most tools is assuming. Conflict management is all or nothing.

Wikis are made to be more realtime… “What you see is what you get”, and assume you always have Internet. It’s hard for us to choose… spend our effort towards realtime or support use-cases that are slowly going away.

Indeed, but XWiki also allows scripting on the database and you can manipulate the data in the system. If you go for structured data, you will have this ability. It is not manual though which is what folders and files allow…

Here the key point is that you get all this from file management, because file management lacks all the interconnection and metadata features. It is more complex to provide in Wikis because you have them.

If you move to Wikis it should not be to replicate files and folders.

Indeed, and this is something that could be improved in XWiki. We’ve talked about the “sharing” URL. We have even talked about a “CryptPad” extension as it would also work with Wikis behind the firewall, but still allow sharing on the Cloud in an encrypted database. If we did this we would get all the features you are mentioning (passwords & limited lifetime).

We’ve talked about allowing Drag and Drop in the tree. This would be nice to help in this area.

It’s supposed to be more advanced, but we noted the bug you have. It’s been introduced by an improvement we did to protect from editing through different methods and we failed to take into account attachment uploads. In XWiki 11.4 we now have a much better method, so we should deactivate the protection in the realtime module. We will look into this to have a version that works well with it and also a version where you can deactivate this feature all-together for older versions.

This is one of the key reasons to move to Wikis is the basis of the differences between files & folders and Wikis, but it’s not the only one. In addition to linking, the choice in Wikis is to allow simpler editing (less features in the editor). It’s actually a choice not to have all the office bells and whistles in the editor. It allows users to focus on the content itself. Users tend to over-focus on the presentation which can go in the way of having actual valuable content. Another aspect is that you have an unbalance between the skills of users at using Office capabilities and some will use it and other not. This leads to some users not participating to documents of other users. In Wikis the objective is to favor collaboration. The key elements for this is to be simple and fast. Now it’s interesting to have better presentation methods for content in order to help readability and also ease editing. The approach in Wiki is to go towards either macros in Wiki documents or towards structured documents with metadata. This makes it much easier and faster for people to make nice documents. XWiki has a powerful macro system which allows you to build your own macros.

Yes this is a serious difficulty a lot of users face. What we suggest in this area is:

Option 1/ Import the office documents and transform them to Wiki pages, which will allow interlinking
Option 2/ If this is not a good solution because the content is very rich, import the documents in a structure data page which would contain meta-data that represents the office documents (categories, etc…) and attach the office file and use the structure data view to insert an office viewer for the office documents. We have also in the past converted the office files to PDFs before attachment them which creates a more consistent user experience but means the documents are not editable.
Option 3/ Keep the documents in NextCloud and create the structured XWiki page that would link to the NextCloud document and possibly add a NextCloud viewer and buttons to collaborate in NextCloud (see later, but unfortunately some tech is missing for that). It could also be possible to automate the Wiki page creation from the NextCloud files being in a specific folder.

This can be done with the batch import tool and creating an excel file representing all documents and including their metadata. The batch import tool can import the office files as attachments and the excel columns are matched to AppWithinMinutes fields.

I see your problem here with 2 different tools. At this point the office editing in XWiki is OnlyOffice. We don’t have better. The alternative would be option 3 and leave the content in NextCloud and use Collabora Code. See later.

I would not go in this direction. The File Manager has been made to bring legacy content in XWiki not to have an advanced user experience about these files. We don’t expect the File Manager to be on par with NextCloud. I would continue to use NextCloud which is a great tool for file management.

It’s unclear how this would work well. You pointed right that we don’t invest too much on WebDAV. The reason is that often it has to be blocked because of enteprise authentication systems and it’s not an option for many companies. Also WebDAV is made for folders and XWiki has a hard time representing the XWiki content as folders & files.

It would be interesting to see if this works and if NextCloud can sync that offline for example. This could be a solution to expose the attachments.
Now maybe what XWiki should have in this case is a WebDAV only focused on the attachments based on the XWiki nested pages structure and then have this syncable over tools like NextCloud. Some experiments would be needed to see if this could be a viable option.

Now what I would try based in the information I have is:

1/ Either importing fully the content in XWiki as structured pages with meta-data and allow editing of these office files from a online editing tool (OnlyOffice at this point or get an implementation of Collabora Code integration → this could be sponsored).

2/ Create (through import or manually) the structure of the documentation in XWiki and keep the files in NextCloud using linking and work on a viewer integration between XWiki and NextCloud similar to what XWiki has with Office365 and Google Apps. Our initial studies show that there is a missing feature in NextCloud to have “public url” for viewers that can be embedded. Some security settings would also be necessary to allow iframe embedding of this NextCloud content inside the XWiki instance. Here there is a integration that could be developed both in XWiki and NextCloud.
The drawback of this solution is that there is no search integration and some integration would be necessary here. In our Office365 module we have included a extension suggesting searches from Office365 in XWiki. With the proper API in NextCloud this could be possible. An alternative approach would be to index the content. As we have the links in XWiki to the NextCloud content, XWiki’s search engine could download the files and index the content provided it has the rights to do so. The content could also be replicated but there is a risk it’s not the latest one if it’s edited in NextCloud and XWiki does not have a way to update the content.

3/ Implement ActivityPub. NextCloud has a federation mecanism and XWiki could implement that mecanism. This would allow to “share” a document with XWiki and it might (this needs to be validated technically) be possible to push a document to XWiki and then have XWiki and NextCloud be informed if the document is modified on either side. So documents could be edited in NextCloud and then pushed to an XWiki page for publication.

This is a different ways I would go. We would be interested in working on integrating NextCloud with XWiki. We believe NextCloud is a great tool and our companies are both trying to liberate users from proprietary softwares. I personally believe more integration between OSS tools is necessary but everybody struggles to find the way to finance it.

Ludovic

5

Hello Ludovic,

Thanks for your thorough answer!

First of all let me clarify that I’m not questioning whether to use a Wiki or not - we’re already using XWiki for a while, missed a Wiki severely before and in general are quite happy with it, such that I signed a silver support contract to support Xwiki development.

It’s just the competition you’re writing about, between XWiki on one side and rich tables or documents from other / foreign sources as well as legacy documents on the other side.

So it really is just about either how to integrate those different documentation sources best or about usage concepts - how to avoid or lessen the need of better integration by using different conventions.

So all of our internal “real” documentation is being created in XWiki only. Its editing and formatting capabilities are fine and I assume will get increasingly better especially as the macro inline editing features in the WYSIWYG editor continue to be improved.

We currently hit limitations there in case of pretty complex tables which we often use as an easy way to manage overview tables or to do polls and the like. Another case is estimation sheets for projects where we actually do need formulas in the table, which would be much more difficult and less flexible to do in XWiki, even using custom macros. Using a spreadsheet application you can just create a table, add some formulas and off you go.

In other cases the tables are just very complex such that you simply do not really want to edit it in a browser if it can be avoided. My comment about editing copies of the files using desktop applications was less about offline editability and more about usability / user friendliness. As good as online office solutions as CODE and possibly OnlyOffice (which I’ve not tested so far) are, a native desktop application still providers better performance and usability.

However, much of this probably could be solved by using XWikis OnlyOffice integration, which I will have a look at in near future - it sound like the most promising way for us to go for now.

I also already noticed that integration could be improved on the Nextcloud side - that’s why I also posted my original thoughts in their forum, however so far I didn’t have a single answer there. Possibly my original post was much too long, tough anyway the support and feedback in your forum is much better than in Nextcloud’s. So thumbs up, the quick reactions from @vmassol and eg. @mflorea were a significant reason for me to stay with XWiki and later actually sign my support contract.

Unfortunately, Nextcloud does not allow direct links to a document’s editing or browsing view for logged-in users. It does so, however, with anonymous public sharing links, which normally is not what I want to do.

(That was actually what I was referring to in my original post, it wasn’t my intention to link from one office document to another within Nextcloud - I more thought about adding links to office documents into the Wiki, which after a click would open the document (or PDF, or whatever) directly in edit mode. It would allow more seamless crosslinking that is possible at the moment.)

I opened a Nextcloud feature request for this last year, but there has not been any action or progress since then: Allow "Direct Editing" Link Without Public Sharing · Issue #12470 · nextcloud/server · GitHub

Concerning OnlyOffice: What was keeping me back was for one, that OnlyOffice is based on OfficeOpen XML while XWiki’s Office Server, also used for rendering document previews and stuff is the OpenDocument-based LibreOffice, so I will have to see if this causes any compatibility problems or if I’m fearing issues here which just do not exist.

Very few of our tables will not be usable this way, they are LibreOffice Calc only and just plainly do not work in Excel, and so most likely also not in OnlyOffice - but those are rare exceptions.

That being said, I’ll try it if it’s the best option we have at the moment. As far as I see, I can get a unlimited usage license for the OnlyOffice connector with a one-time payment?

As a personal aspect, the development of CODE / LibreOffice online is “more open” than the OnlyOffice development, which I personally prefer. On the other hand of course I also fully understand that implementing an online office integration is much work and takes much effort, and as such you cannot offer connectors for every immaginable foreign software package out there.

Also probably Xwiki is too rarely used for Collabora to implement the integration from their side, though maybe it might be an idea to talk with them about it - maybe if you also find additional sponsors among your customers. (Nextcloud and Collabora partnered somehow and made quite some fuss around that, publicity wise.) I also already asked your support colleagues about possible sponsoring models in general - as, as a 7-person-company, our possibilities there are limited - and am eagerly waiting for a reply. (This question was not related to CODE integration, though, as sponsoring this probably would exceed our possibilities in any case…)

I’m not trying to do.

However for example we have an icon collection consisting of thousands of icon files, which should probably stay in Nextcloud. Also we have foreign documentation of a standard we’re working with, which consists of hundreds (!) of PDF files distributed over some dozend directories - that’s probably also something where integration into XWiki does not make too much sense, or how would you takle that?

So there’s a bunch of data comparable to this, plus the stuff already mentioned above.

Meanwhile I tried that, but it only sort-of works. I can attach XWiki to Nextcloud as an external WebDAV storage, and it’s mounted and presented as a new folder in the Nextcloud interface. I can access it, but many operations lead to an Exception being logged in Nextcloud, in which case I’m redirected to the root folder. This issue is also known on the Nextcloud side, but I cannot currently find the issue number. Also indexing the XWiki contents does not work probably due to the same problem - Nextcloud starts indexing the remote storage and soon terminates this process with an Exception. However probably it’s no big deal. As I do not assume that Nextcloud will do anything about this anytime soon, I may try to have a look at this myself, even though I’m probably also lacking the time…

Probably more important is that the performance is not really good, so not sure how practically usable this approach would be. Nevertheless attachment focused WebDAV access sounds very interesting. It probably even does not hurt to have the occasional Wiki page data floating around as text files, as it’s at the moment. What’s more problematic is that much of the content is exposed redundantly via multiple pathes. (I’m only talking about the “spaces” folder, it’s obvious that content is presented redundantly through the other special folders.)

However from my point of view the mapping from XWiki spaces to folders with files fits quite well, at least more or less. Why do you think its difficult to represent XWiki’s content as folders and files? Besides the redundant pathes my impression was that it seems to look quite straight-forward the way it’s done by the WebDAV server extension. Or are you referring to the reason those redundant pathes exist at all?

Another idea: Do you think a WebDAV client extension for XWiki would be doable, which would expose all files in a WebDAV directory as “virtual attachments” in a given XWiki page?

As I wrote I also noticed the missing viewer / editor access API (Allow "Direct Editing" Link Without Public Sharing · Issue #12470 · nextcloud/server · GitHub which I opened last year), but I’m currently pursuing this route. I’m adding links to Nextcloud to my XWiki articles and try to annotate them with relevant key words so the links are also found if being searched for. I also installed the Nextcloud README.md app (README.md - Apps - App Store - Nextcloud, you should wait for the next release which fixed a bunch of significant bugs in 1.0.4 which I reported after testing it) and am adding lots of HEADER.md and README.md files to my Nextcloud folders which point back to XWiki, wherever appropriate.

I replicated the same basic hierarchical structure in both XWiki and Nextcloud, such that my documentation and documents is categorized in similar ways in both systems.

Still it’s annoying not to be able to reference documents in XWiki in a way which seamlessly opens them in edit or viewer mode. :frowning: I would imagine this to be a great enhancement for this use case - especially as it’s already supported for public share links. Unfortunately, there’s not much XWiki can do in this case, I assume.

Concerning ActivityPub, I’ve read that it exists, but have never tried it so far. I could be an interesting route to pursue, but I’d hope that it actually fulfills its promises. When I tried End-to-end-Encryption - which was announced as a big feature in NextCloud 13 - it was a hard landing because even with Nextcloud 15 it simply still does not work and is not usable - and there is no timeline, when it will be and no official reaction from the Nextcloud devs, unfortunately. (Also see Status End2End-Encryption in NextCloud? - #3 by GOhrner - end-to-end-encryption - Nextcloud community and related posts concerning this.) So I’m a bit careful now whenever it comes to more advanced features Nextcloud is supposed to support… :wink:

Regards,

Gunter

6

@ludovic: Concerning the suggestion to import existing Office documents:

One problem this approach currently has is that the document’s original structure is not rescued well into the imported result.

In order to properly benefit from the import and to be able to utilize XWiki’s features and the wiki concept on the result, importing in my point of view only makes sense for most documents, if it’s split into separate pages for each original chapter or section (the level of splitting depending on the original document, of course).

Otherwise we just get a huge Wiki page with linear content, which cannot easily be linked to, navigated or restructured afterwards.

Now while the XWiki Office Importer supports splitting a document just fine, the result of this procedure is not really immedately usable, as the chapter ordering and (sub-)structure is basically lost in this process, resulting in a huge “pool” of more or less randomly ordered sibling pages in a big list.

I added some wishlist entries to JIRA with features which - in my point of view - could improve the Office Importer’s results a lot, and which would also help “original” Wiki content, i.e. which are not specific to the Office Importer extension.

The following wishlist entry is specific to the Office Importer, but references the more generic feature suggestions it would benefit from once those are implemented:

XWIKI-16575 “Office Importer: Keep Original Document Structure Even With “Splitting” Import”
https://jira.xwiki.org/browse/XWIKI-16575