we are testing the Realtime WYSIWYG Editor extension (XWiki version 15.2). A second editor cannot access a page, the message is always “This page is currently locked by …” and we can either cancel or force edit, which does not result in a collaborative session.
Second thing that bothers me is that with Chrome and Edge there is an error message when editing a page - even as first editor:
We were unable to connect you to the realtime system.
You won’t be warned if other users want to edit the document collaboratively and you can’t join a collaborative session.
whereas doing the same thing in Firefox just opens the editor as expected. Collaborative editing does not work though. I disabled all referrer settings in nginx, but that does not help. Might this be related to https?
to nginx, the browser issue as been resolved. Still, a second editor cannot join a collaborative editing session. I cannot see anything in the log which I could connect to this issue. Any indications, what I should look for in the logs?
yes, this behaviour is a limitation of editor, related to the way it’s deployed (as an extension).
It’s like that for now because the extension is experimental, but it’s not planned to be like that in the final, production-ready version of the editor.
Having the realtime session joined automatically needs a modification in a piece of code of XWiki that cannot be made by an extension that gets deployed through extension manager. So changing this behaviour would imply making a modification in the product to allow an extension to inject a different behaviour in the lock screen.
If you want to test this you can make a code modification on your XWiki instance, but if you want to keep this change you will then need to maintain this customization on your side. Here’s what you’d need to do:
copy the content of the original .vm for your instance from the templates/edit_macros.vm file of your wiki
customize this vm as follws:
Just after the line #elseif ($tdoc.getLocked() && !$editForced), add the following block of code:
##
## Custom for RT editing: check whether there is a realtime editing open for the current mode and current language (and there is a user in it).
## Confirmation is only needed if there is no realtime session open; when realtime is open, go directly in edit mode to join this session.
##
#set($isRealtimeSessionOpen = false)
## check the current editor, code copied from edit.vm (ideally it should be done in edit.vm before confirmation)
#set($currentEditorForRTDetection = $NULL)
#if ("$!editor" == '')
## Normally no special characters should exist in the editor parameter, so this is just a protection measure.
#set ($currentEditorForRTDetection = "$!{escapetool.xml($request.getParameter('editor'))}")
#if ($currentEditorForRTDetection == '')
#getDefaultDocumentEditor($currentEditorForRTDetection)
#end
#else
#set($currentEditorForRTDetection = $editor)
#end
#if ($currentEditorForRTDetection == 'wysiwyg')
#set($rtSession = $services.netflux.getChannels($tdoc.documentReference, ["$!tdoc.realLocale", 'content', $currentEditorForRTDetection]))
#if ($rtSession.size() > 0 && $rtSession.get(0).userCount > 0)
#set($isRealtimeSessionOpen = true)
#end
#end
#if (!$isRealtimeSessionOpen)
and then close this #if about 12 lines lower, after the lines
In my company we have a test instance with v15.2 running too and met with the same issue. Strangely once we have been able to write on a wiki page in real time with 2 persons during a few minutes (then I go a message with an error), but we have no idea what had made it work.
I am going to try the method describe above by lucaa, and be be back for questions or to say it it helps.
As written on the extension page for the Skin Application, that extension is bundled with XWiki Standard Flavor (check the grey box on the top right). So if you installed standard XWiki without making your own flavor for it or something, you have it already, you don’t need to install anything to use its features.
I have tested the suggestion you brought up for " CaS4YumEE35lJo1UNAhr" in XWiki 15.3 and unfortunately it hasn’t helped making it work.
Was it intended only for a v15.2? Or should it have been working in a 15.3 installation?
In the attached screenshot, I had two accounts, one in a private window. In one test I had an admin account (developer rights), in the other a simple user.
In another test, I had two simple users trying to write simultaneously on the same page. You can see the results. (I wanted to post 2 more screenshots but the forum won’t allow it).
Maybe until all this is stable, I’ll try another Realtime Editor extension.
The suggestion I wrote above is for the specific problem of having the page locked when a second user tries to join the session. namely when you see this screen, or similar, and you need to click “Force editing” in order to join the collaborative session:
You seem to be having a different problem here, both your users see an editor but one of them cannot connect to the collaborative session. If the second user that arrived on the edit URL of that page did not see the locked page message, then my code above worked, provided that you have the right realtime extension installed (see below).
If you really mean here “another Realtime Editor extension of XWiki” and not “another platform instead of XWiki”, then please know that there is, for XWiki, a single Realtime Editor extension that is “to be used”. There are indeed more than one on the extensions store, but one supersedes the other.
You may find help on this forum for this other problem as well, but it would probably be best to ask it in a different thread, as this one is for the lock problem specifically and keeping things clear helps direct energy to the right place.
You can check whether your problem is the lock problem or a consequence of it like this:
remove the fix that you added following my code above
edit a page with user A
edit the same page with user B
this user will now see the ‘lock screen’ message that I put above
click “Force editing” with user B
the editor loads to user B
you should now have a collaborative session with user A and B
if you don’t, then you have a different problem than the lock problem.
Regarding the main issue here, the “Force editing” button:
I have upgrade to 15.3 and implemented your workaround in edit_macros.vm and can confirm that it works and suppresses the warning. Thanks a lot!
You mentioned this would eventually go into the production-ready version. Any estimate how far down the road that is ready? Anything we can help with testing?
There is a plan to put the real-time editor back on the XWiki roadmap for the second part of the year, but nothing is set in stone. It’s very unlikely that we’ll work on it in the next few months, so you’ll have to wait a bit. As for testing, that is always welcome and very much appreciated. Any progress on the real-time editor will be announced in the release notes so you should check that. You can also check the current roadmap.
You seem to be having a different problem here, both your users see an editor but one of them cannot connect to the collaborative session.
Hi Anca,
he have met with both. And yes, I really mean here “another Realtime Editor extension of XWiki”.
The one tested is the right one, Realtime WYSIWYG Editor which superseeds the others.
Apart from the debug mode page ( https://dev.xwiki.org/xwiki/bin/view/Community/Debugging ) is there any specific method related to extensions which could be put to good use to bring messages back here?
I’d like to report about a research I have done on the web yesterday, which makes me think some more direct solutions might perhaps be possible to use and somehow at reach.
One possibility would be related to CKEditor which is the default in XWiki, (I don’t know which version is implemented in XWiki 15.3 though),
