Realtime WYSIWYG Editor Page locked

Help / Discuss
#1

Hi there,

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?

Thanks for helping me out with this.

#2

Ok, by setting

xwiki.url.protocol=https

in xwiki.cfg and adding

proxy_redirect     http:// 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?

#3

Hi,

so if we force editing, the collaborative sessions starts. Is this supposed to be like that?

Thanks

#4

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:

  • have a custom skin in your wiki as described in Skin Application (XWiki.org)
  • override the edit_macros.vm template as described here Skin Application (XWiki.org)
  • 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

      'confirm': $services.localization.render('forcelock')
    })

by adding the following line:

    #end

Hope this works for you.
I tested it on XWiki 14.10.x on my side, but it should work the same on 15.2.

1 Like
#5

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.

Thanks for your work.

#6

@lucaa Thanks for the detailed description. We will test the workaround in the next couple of days too, in our next test cycle.

#7

@lucaa, I have updated XWiki to 15.3, as well as its current upgradable extensions, however Skin Application (Skin Application (XWiki.org)) does not show in the Extension Manager. Is that normal?

#8

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.

#9

@lucaa hello,
I don’t see any such grey box on the top right. (Firefox 102.8.0esr here).
Screenshot-XWiki-Skin-Extension

#10

see “bundled with” in your screenshot :slight_smile:

#11

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?
2023-04-24_16-14

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.

#12

Ok, thank you very much.

#13

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:

image

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.

More specifically, this https://extensions.xwiki.org/xwiki/bin/view/Extension/Realtime%20WYSIWYG%20Editor/ is the one to try, that was more recently updated, will be maintained and improved in the future, while this: Visual Realtime Collaborative Editor (XWiki.org) is the older one that is not maintained any more.

Hope this helps,
Anca

#14

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.
#15

I agree, different topic. Just one remark: We faced a connectivity issue at first as well with Chrome and Edge browser. After adding the redirect in nginx mentioned here Realtime WYSIWYG Editor Page locked - #2 by CaS4YumEE35lJo1UNAhr it worked.

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?

#16

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.

Thanks,
Marius

After upgrade to 15.6 Realtime WYSIWYG Collaboration does not work
#17

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?

#18

Hello Marius,

first thank you for your information.

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),

CKEditor version 5 can be used with a very well working Realtime collaborative edition feature. Online Document Collaboration Software | CKEditor 5 Features

I have tested it online quickly, with two different Firefox browser sessions, it worked instantly. (I enclose a screenshot).

CKEditor-v5-RT-collaborative-editor-2023-04-28_11-48

To test it, I used this demo page:
https://ckeditor.com/collaboration/demo/#real-time-collaboration

(Me means me, and Moi means the same but typing in the other window)

However it is a premium feature. (Could this be an obstacle ?)

Another possibility might exist, with https://tiptap.dev on their website it says it comes with a MIT licence allowing to do whatever one wants with it, and has native RT editor (but some other features available are pro/premium : Headless WYSIWYG Text Editor – Tiptap Editor

I hope you can tell me if one of the two ideas could be a good one and workable in the XWiki context?

#19

Thanks a lot! We will use the extension now in our test environment and provide feedback if we find something.

#20

Normally the latest 4.x version.

Yes, that’s a blocker for us.

Well, we already have a good real-time synchronization algorithm, that’s not the problem. See https://cryptpad.fr/ . We’re basically reusing CryptPad’s real-time engine (ChainPad, see ChainPad and Listmap — CryptPad 5.2 documentation and GitHub - xwiki-contrib/chainpad: Realtime Collaborative Editor Algorithm based on Nakamoto Blockchains). What we need to do is to tweak / improve the integration in XWiki. And we plan to do this by the end of the year.

1 Like