Here is the list of related plugins installed, can you tell me if I should remove some of them or else?
Then I’ll add a screenshot to state that the xwiki-realtime option does not appear anymore either in the Admnistration section related to Edition options.
About the above configuration, I tried to untick xwiki-realtime in the drop-down menu containing the list of extensions, I also tried the reset button located near the save button, but the xwiki-realtime still doesn’t appear as a choice to replace CKEditor.
Is CKEditor supposed to do the job by himself? I have tried that too, and could not get realtime editing between two different users.
Also about the part of the discussion related to in-place editing also in the previous post, it is not showing this behavior anymore although I have not changed the xwiki.properties related line. It is still setup on the original default:
#-# The default is:
# edit.document.inPlaceEditing.enabled = true
therefore now I am confused wether or not in-place editing should trigger a narrow edition line in new pages.
A detail : we have upgraded Debian to version 12 bookworm and replaced Tomcat9 with xjetty. This is the only other change I can think of.
I also meet with the same Realtime WYSIWYG collaborative edition issue in our LTS installation which is now version 15.10.10.
What is similar in both installs : we use Debian 11 in both, and we have switched from Tomcat9 to Xjetty ( xwiki-xjetty-pgsql), and not yet in Debian 12.
Does someone know if it usually ok to use realtime edition with this setup?
Realitme Editing is no longer a standalone Editor it is now a plugin of the CKE editor. You have to untick xwiki-realtime from the disabled plugins. This way realtime editing now also works in place.
Force editing is still required and it will probably stay that way, until realtime editing is considered stable and enabled by default.
While I am looking at the list of default disabled plugins, I would like to ask what the other disabled plugins do, and if they need to stay disabled for the time being?
Here is a new screenshot:
Some plugins are disabled because we provide an XWiki specific implementation (sourcearea vs. xwiki-sourcearea) and others are disabled because their focus is styling the content, and we want to discourage this. Your users should focus on the content itself and let the styling be managed by the wiki, in order to have a consistent L&F across your wiki pages.
