[XWiki 16.2.0] New issue with Editor along with RT Collaborative Edition

Help / Discuss
#1

Hello,
when the time had come to update from XWiki 15.10.5 to 16.0.0 at the beginning of February, the collaborative edition was working, though with a Force button for the second person coming to edit at same time, and the editor was just normal.

Same on 26th February, when updated to 16.1.0.

I updated to 16.2.0 on march 27th and had only today had the time to test again, and this time it isn’t ok anymore.

Here 2 screenshots. One you can see the field for the edition content is very short, and there is not handle to open it larger. The other one, there is conflict between the two test users trying to test the collaborative edition together.

Screenshot 2024-04-03 at 17-47-55 Fast test on RT Collaborative Edition v16.2 April 3rd - XWiki

Screenshot 2024-04-03 at 17-47-00 Fast test on RT Collaborative Edition v16.2 April 3rd - XWiki

Something I am also in a wonder : how come I had an update to upgrade to 16.x.y in the first place, whereas I have seen newer versions on the 15.x.y branch? I guess because we use the stable branche? (http://maven.xwiki.org stable/)

How is the LTS doing these days? If I want to speed up the tests and be able to move forward in direction of the Confluence migration and setup for production in a time not too far, would the LTS be now a better choice?

How can I fix the two bugs I just hit on the branch 16? Thanks for your help and insights!

#2

Realtime editing is currently still an unstable feature.

Still realtime editing is getting closer and closer in XWiki and you always have too keep in mind that XWiki converts everything in the editor into XWiki Syntax and also allows for huge amounts and variety of macros (even self programmed ones) - as far as I understand it these both things are making it so hard for realtime editing. But at the same time they are the reason why XWiki is so super flexible and extendible.

Because of this you probably should not expect the realtime editing to be on an super solid confluence like level where you basically don’t have to think about it. („it just works“) At least not in the super near future. I guess best chances for that rock solid realtime editing without worrying about anything is getting more likely to happen, when they implement the upcoming Editor - which is not choosen at this point.

In our very short 16.2 tests with inplace realtime editing, we had huge freezes but the gui and integration is already looking good. We disabled it again and are using 16.2.

For your decision with 15.X: as it is an LTS version it will probably not be getting any new major features and also it won‘t get any small features and changes that can break compatibility or look and feel.
That is the whole point of LTS as you won‘t have to worry about an new current release changing stuff that you and your users were used to.

In the other hand the current / stable release always get the new stuff and you feel the development progress very much (in an clearly positive way!)
If you care for constant improvements that can possible change stuff and might not be 100% stable, then current / stable release is the better choice. Most of the times if things won‘t work completely like intended the fix is a month away till the next version comes out. And real issues get hotfixes.

For our Organisation the stable branch is the way we prefer. But we have an secondary server for testing updates first - I highly recommend doing that especially for the faster stable branch.

1 Like
#3

Thank you for your insights, this is really helpful. Also for the time being we are still testing, so I guess wether or not we will have a similar setup as your’s or rather one stable and one LTS will be decided later.
Has the bugs I present here been experienced by other users or by the dev team?

#4

Hi,

This is standard in-place editing. You get the same if you disable the real-time editing (which seems to be the case in your screenshot :slight_smile: ). I’m not saying it’s nice (I agree the editing area should have a minimum height set that is a lot larger than 1 line of text), but that’s not related to real-time, and it’s certainly not a regression in 16.2 (we have this behavior since we introduced in-place editing).

I noticed this one, and I’m planning to hunt it down, but in my case it happens rarely. Do you get it all the time? Or very often?

Yes, sorry about this (I noticed this too late for 16.2.0 because in my tests I usually have small content for which this problem is less noticeable). I’m fixing Loading... in 16.3.0 (almost done).

Yes, dynamic macros are tricky, but we should have good support for them in real-time edit in 16.2, and I’m also fixing some issues for 16.3.0. One of the complexity comes from the fact that macros need to be rendered server-side, which is not instant (needs an HTTP request), and I need to render the full content, not just macros individually (because one macro call can influence the output of another macro call, especially for script macros). One problem I’m having for instance is that if you’re typing and at the same time you receive a remote change that includes a macro call change (e.g. a macro parameter change) I need to re-render the content, so I’m locking the editor while you’re typing, which is not nice because you may lose some characters or worse you may trigger some shortcut keys (that get enabled when the editing area is read-only).

Thanks both for testing the real-time editing and for your feedback.

1 Like
#5

Hi @mflorea

This is standard in-place editing. You get the same if you disable the real-time editing (which seems to be the case in your screenshot :slight_smile: ). I’m not saying it’s nice (I agree the editing area should have a minimum height set that is a lot larger than 1 line of text), but that’s not related to real-time, and it’s certainly not a regression in 16.2 (we have this behavior since we introduced in-place editing).

This is the first time I’m meeting with this behavior in XWiki, and it’s been about a year I started to test on it.
Also, for collaborative edition sessions, I don’t think it would be very handy…
Is there a way to switch it to the other way (not in-place editing) ?

#6

Yes, see https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Configuration/#HIn-placeEditing .

#7

You’re probably aware of this, but just mentioning to be sure: when editing in-place the editing area resizes dynamically to fit the content. You never get vertical scrollbars. So you don’t need to resize it manually, it happens automatically when you add content.