I am experiencing issues with unwanted Autosaves when working in the WYSIWYG editor, even though Autosave is not available as an option in the WYSIWYG editor and is deactivated when switching to Wiki editing.
The behavior is reproducible in XWiki versions 15.10.x. Steps to reproduce:
@CycleSEC This is quite new (having the realtime editor be the default) so any feedback is interesting and good, thx
I agree that it feels weird to have both a “Save” button and an autosave as it can be misleading and users may think they need to click the save button to save. I feel we need to do something about this.
From my perspective, autosave compromises the integrity of a page during editing as it is implemented at the moment. It saves changes mid-process, often with incomplete sentences or scripts, before I’ve had a chance to review or finalize them. As a result, if someone accesses the page during this time, it may appear incomplete or even broken, especially for unfinished scripts. This undermines the Preview button’s purpose, as it no longer reflects pending changes but rather what’s already live.
The most confusing aspect for me was that clicking Cancel only discards changes made since the last autosave, not all edits since opening the editor. This behavior feels counterintuitive and can unintentionally retain undesired changes. Additionally, autosaves clutter the version history and require users to manually revert to the last intentional save after clicking Cancel, increasing complexity and the risk of errors.
Another issue is that autosaves are indistinguishable from regular saves in the version history. They appear as user-initiated changes, even when they are initiated due to a system setting. This undermines version control by making it unclear which changes were deliberate. Even the user themselves cannot distinguish these changes if the previous edits were minor. They would need to manually compare the versions to identify the differences and to find out what was the last manually saved version.
Proposed Solution
To address these issues, autosaves could be stored as temporary versions (e.g., MySpace.MyPage.TempHome) rather than the primary version (...WebHome). These temporary versions would be deleted automatically when the user finalizes their edits by clicking Save or discards them with Cancel. If the user stops editing for another reason, such as closing the browser tab, the system could prompt them to resume their temporary version upon returning. (I believe this is how it works in WordPress, although I’m not sure if WordPress supports collaborative editing.)
This approach ensures incomplete changes aren’t published prematurely while safeguarding in-progress work. It also keeps version histories clean and aligned with user intent.
I would second your feedback. The autosafe issues that you are describing are a major reason why we are currently not confident in enabling realtime editing because it would probably confuse our users. The loss of “simple” version control is also a bit problematic.
The cancel button behavior especially is a big usability issue. This really should work more like the described solution or/and like it is in Confluence: Realtime session are autosaved “drafts” (which can even be saved more often than every five minutes) and these drafts are not applied to the pages unless someone hits a “publish” button. Before the publishing of the draft, it is accessible via opening or joining an editing session.
The current use of the autosafe feature really feels like a crutch solution instead of a “realtime native” one. Maybe a “draft and publish” solution could even be implemented without a lot of new tech. The “pulish” wording would also be very fitting and help the users understand the system easier.
First, thank you, @CycleSEC, for your feedback and suggestions.
What you describe here is true for Save & Continue action as much as it is for auto-save. Are you telling us that in your organization users are forbidden to save the page they are editing until the page is complete (no unfinished paragraphs or sections, no typos) and all the scripts are working perfectly? I seriously doubt this. When I edit a wiki page (most of the time using the Wiki editor) I use the Save & Continue shortcut key (Alt + Shift + S) tens of time, if not more, fearing not to lose any change. When dealing with scripts, I modify, save, reload in a separate tab, repeat. I never wait until the script is “finished” to save.
Now, the pages I’m editing (e.g. on xwiki.org) are not accessed at the same time by tens or hundreds of users, so I can afford to have them in an unfinished state for a short period of time (e.g. 15 to 30 minutes), until I finish editing. I prefer saving (explicitly) unfinished work often over loosing unsaved work.
If you can’t afford to have unfinished work then I think you need to look at extensions such as:
Extensions like these add support for creating drafts that are published when the work is finished.
The WYSIWYG editor doesn’t have any Preview button. Are we talking about the WYSIWYG editor?
Replace “autosave” with “Save & Continue” and everything you said above stands true. You seem to suggest that users are saving explicitly / intentional either at the end or after having some intermediary polished state, but that’s not what I do, and not what I’ve seen others doing. If you save (and continue) obsessively like me (using the shortcut key) then yes:
the Cancel button is pretty useless (I revert to the version before I started editing if I need to drop all my changes)
the history has lots of minor versions (both Save & Continue and auto-save generate minor versions), but I can manage by doing a Save & View at the end with some comment, or whenever I have some polished state.
Again, in your view a deliberate / explicit / intentional save is done only when the content is in some well defined (polished) milestone state. My point is that users are often saving unfinished work just to avoid loosing changes, and these revisions of unfinished work are not much different than the revisions created by the autosave.
Some questions:
is it your draft or everyone’s draft?
if it’s only your draft, then aren’t you worried that multiple users drafting the same page will overwrite each other’s changes?
if it’s a shared draft, then I would be surprised to see something in view mode and get something else when trying to edit; I’d probably drop the unsaved changes (your work) and start from what I have in view mode
As I mentioned above, this need of having drafts is covered by some XWiki extensions (notably the Change Request Application and the Publication Workflow Application).
The Confluence implementation is far from perfect… The draft is shared, but if you’re not the one that created the draft you don’t see “Unsaved changes” in view mode. Imagine you notice some mistake (e.g. a typo) and you want to fix it. You edit, and you can’t find the mistake you want to fix because you’re editing a draft that you didn’t create and that is different from what you saw in view mode. Furthermore, you’re the only user editing at the moment, so where does this different content come from? Who created this draft?.. Can I revert to the previous version to fix the mistake I saw in view mode?
Note that other tools like Notion doesn’t use drafts (AFAICS) and what you’re editing is directly seen and available to others accessing the same page. So I don’t think using drafts when editing in realtime is the norm. I personally wouldn’t build drafts into the edit mode but rather have them outside, i.e. allow the user to explicitly create a draft it they don’t want (or are missing the rights) to edit the page directly. But again, this is already implemented (to some degree) by XWiki extensions such as Change Request Application and Publication Workflow Application.
Thanks for the explanation!
In my opinion a shared draft is not problematic (and probably the only way to realize drafts without some extensive merging functionalities) but that is just a design decision regarding the aimed functionality of the product. Just to round this up, I see two options here for realtime editors:
1. Page Edits are visible immediately (XWiki, Notion)
Directly visible due to automatic saves
No drafting (drafting meaning changes are saved on the server but are not directly visible)
The reading users could see unfinished/broken documents but…
everyone always sees and works on the newest version
The Version history has a lot of entries and rollbacks targets might be difficult to identify
2. Page Edits are not immediately visible (Confluence)
Edits saved in Drafts (saves on server) that are only visible upon publishing
The current draft status is only visible when starting to edit
Actual Page and Draft could differ substantially
The draft is identical for each person (meaning there could be a “suprise” when a person would like to edit but the draft is totally different)
The version history stays cleaner compared to approach 1
Your explanation helped me in understanding XWikis approach better. Especially the minor versions help a lot and I think it works but maybe could be improved in terms of integrated user education.
The main issue I see here is the minor revision concept and the rollback targets. In my opinion the UI/UX could be improved by:
making it more clear that minor revisions are created automatically during editing and major ones only when explicitly pressing save (the minor revisions checkbox next to the automatic saves checkbox could be confusing, I think relations are not fully intuitive here)
adding some indication of what “cancel” really means in the Realtime context, for example a popup or something that informs the user that the last autosave minor revision is applied when cancelling and that edits from before the session can be reversed by picking the last major version form the history tap
With your explanation, I now feel confident that I could introduce Realtime on our instance. But I would probably still have to write a tutorial for our users to make sure that there is no confusion regarding the minor versions, cancel button and picking rollback targets. Of course educating my users is partly my responsibility but I think some changes in the mentioned areas would benefit all new XWiki users and reduce the need for extra education measures.
Additionally one last point (happy to create a new topic if too far fetched): Do the minor version impact performance in any ways? The increase in Versions per Page should increase dramatically when enabling Realtime so I am wondering if I should prepare our Instance in some way. Furthermore, how would the change to not storing diffs impact this? See Stop storing diffs by default in the history - #6 by MichaelHamann
The number of revisions used to not scale very well but @pjeanjean worked on it last year (see for instance Loading... ) so it should be fine now.
AFAIK, the benefit of this change is mainly for pages with lots of objects (e.g. group pages), but realtime editing is less common for this type of pages (i.e. for structured pages). So I don’t think you need this change to use realtime editing.
That depends on the use case, but yes, in some situations, this is necessary. For scripting in ISO/IEC 27001-compliant environments, this approach is mandatory. ISO/IEC 27001 control 8.31 (Separation of development, test, and production environments) requires the strict segregation of these environments.
You’re right. I initially thought my WYSIWYG editor had a Preview button as well. Looking more closely, it turns out it only appears when real-time collaboration is disabled. However, the Preview button does show up in the wiki editor with different autosave settings (autosave off) even if I switch between the WYSIWYG editor and the wiki editor without saving (which I do quite often).
Yes, that’s correct. That’s our usual practice when working in production environments, where every change must be carefully controlled and documented in the summary. Only typos and minor edits are published with a quick click. If a page requires a major review, it goes through a dedicated review process on a separate page and is republished only after the work is complete and all stakeholders, including those outside the XWiki user space, have approved the draft. In more traditional corporate settings, high-ranking managers (and some others) typically do not edit wiki pages themselves.
As we use XWiki in companies and organizations that are ISO/IEC 27001-compliant or aim to achieve compliance, it is essential no two or more individuals edit a page in scope of the ISMS simultaneously without coordination or aligned objectives. Such practices would violate several ISO/IEC 27001 requirements, specifically:
6.2 (Information security objectives and planning to achieve them): Aligning all activities with defined security objectives.
7.5 (Documented information): Ensuring the integrity and reliability of documented information.
8.1 (Operational planning and control): Establishing processes to ensure consistent outcomes and controlled changes.
The same applies when following other ISO standards, such as ISO 22301 or ISO 45001.
From an ISO perspective: There should not be any drafts in a production system unless they are clearly labeled as drafts
My initial issue was that autosaves occurred unexpectedly for me. I had assumed that clicking Cancel would discard all my work, similar to how quitting without saving works in Word.
For me, it would be much clearer if the checkbox explicitly stated Allow Real-Time Collaboration and Autosave Every 5 Minutes instead of just Allow Real-Time Collaboration. I wasn’t aware that enabling real-time collaboration also meant enabling autosaves.
Aside from the ISO stuff (where the mentioned extensions could maybe help), this again comes down to a need for better integrated user education. I think your idea of changing the realtime checkbox text to mention autosave would also be a nice improvement (in addition to mentioning the effective rollback target of the cancel button somewhere).
So you’re using a separate draft page for bigger changes. Do you have to be as strict with the saves on the draft page? I’m trying to understand why the history of the draft page is so important. When the content is “republished”, are you taking also the history from the draft page or simply create a new version on the original (published) page?
Also, is realtime editing on the draft page useful for you (putting aside the auto-save behavior)? What about realtime editing on the original (published) page? I guess that’s out of discussion right?
The thing is that realtime editing needs auto-save. When you are editing alone (and no one else can join), you are the only one responsible for saving your work, and you know it. So you save whenever you think it’s needed. When you are editing the same page with others:
“all” of you become responsible for saving, BUT, as we know, when all are responsible, none do it (because “other’s will save for sure”)
you know when your change is in a polished state, but you don’t know about the others editing at the same time; if you save, you can catch others in the middle of an unfinished change. Even if you are in a call, talking to each others, it’s not always easy to synchronize a save when everyone editing is ready (their changes are polished).
version increment needs to be propagated to all editors, otherwise you get merge conflicts; each editor instance knows the page version they are editing, and this version is submitted on save and checked with the page version from the server; if they don’t match a merge conflict occurs; the realtime editor avoids merge conflicts by making sure the auto-save is not triggered at the same time by multiple editors. Whenever an editor instance wants to save it notifies the others so that they don’t save at the same time. Without this auto-save protocol the users would have to talk to each other (chat or voice) to synchronize on saves. This is not easy.
For these reasons, realtime editing needs auto-save. This also means that it’s not easy to have a clear revision history for the duration of a realtime editing session. We can aim for marking the start / end of a realtime editing session in the page history, grouping or folding the minor edits under some “realtime edit” version, but I’m not sure if we can do more.
There’s also the option to disable auto-save while editing alone, but the problem is that other users may join or leave without you noticing. I’m not convinced that turning auto-save on and off is a good idea.
As for the checkbox label, I find it too long to also mention auto-save. As I said, for me realtime implies auto-save.
I know we don’t have this currently, but maybe this could be an opportunity to introduce some kind of “inline help” with, e.g., a question mark icon after the label that on hover, or when clicked shows a small help text that explains shortly what realtime editing is and that changes are saved frequently as minor versions when realtime editing is active?
However, the Preview button does show up in the wiki editor with different autosave settings (autosave off) even if I switch between the WYSIWYG editor and the wiki editor without saving (which I do quite often).