js
class Editor extends ClassicEditor {}
Editor.builtinPlugins = [
Bold,
Essentials,
Heading,
List,
Paragraph,
RealTimeCollaborativeEditing,
RealTimeCollaborativeTrackChanges,
];
export Editor;
js
Editor.create(document.querySelector('#editor'), {
initialData: "",
plugins: [
'Essentials','Paragraph','Bold','List','Heading','RealTimeCollaborativeEditing','RealTimeCollaborativeTrackChanges',
],
toolbar: [
'heading','bold','bulletedlist','trackChanges'
],
cloudServices: {
tokenUrl: () => Promise.resolve(getJwtCkEditorToken()),
webSocketUrl: CKE_WEBSOCKET_URL,
},
collaboration: {channelId: "test-text-channel-123"},
})
.then(editor => {
window.editor = editor;
});
editor.data.set(`<suggestion id="e05fe0ef7a56be8063bb94c6caf6e1b3d:USER1" suggestion-type="formatBlock:fz6284npvaph" type="start"></suggestion><p>asd<suggestion id="e05fe0ef7a56be8063bb94c6caf6e1b3d:USER1" suggestion-type="formatBlock:fz6284npvaph" type="end"></suggestion></p>`,
{suppressErrorInCollaboration: true});
editor.getData();
B) option (just div extra wrapper for initialData)
editor.data.set(`<div><suggestion id="e05fe0ef7a56be8063bb94c6caf6e1b3d:USER1" suggestion-type="formatBlock:fz6284npvaph" type="start"></suggestion><p>asd<suggestion id="e05fe0ef7a56be8063bb94c6caf6e1b3d:USER1" suggestion-type="formatBlock:fz6284npvaph" type="end"></suggestion></p></div>`,
{suppressErrorInCollaboration: true});
editor.getData();
The both results(A and B) should be the same or B should throw exception.
A =>
<suggestion id="e05fe0ef7a56be8063bb94c6caf6e1b3d:USER1" suggestion-type="formatBlock:fz6284npvaph" type="start"></suggestion><p>asd<suggestion id="e05fe0ef7a56be8063bb94c6caf6e1b3d:USER1" suggestion-type="formatBlock:fz6284npvaph" type="end"></suggestion></p>
B =>
<p> </p><p>asd</p>
Result should be the same as A or an exception should be thrown.
If you'd like to see this fixed sooner, add a ๐ reaction to this post.
cc @scofalik
I confirm that in option B additional paragraph is created. I'd guess this is because the <div> is not empty, and autoparagraphing changes it to <p>, or similar mechanism is fired. I didn't debug it because it won't be a problem since the next release which will be available in a few days.
In the next release we are introducing a new way to convert markers. Your new data should look like this:
<div><p data-suggestion-start-before="insertion:suggestion-1:user-2">asd<suggestion-end name="insertion:suggestion-1:user-2"></suggestion-end></p></div>
Now, markers that are right before/after an element are stored as attributes. Only markers "in text" are represented by tags. I hope this will resolve your problem.
I've tested loading the above HTML and it worked as expected.
@scofalik, @lslowikowska - Wow.
It is very very big changes for us, I mean - changing suggestions markup approach...
As I see in your markup example - there will be no more <suggestion></suggestion> tags???
In our application we use them for generate word documents, and generate new suggestions on server side (for new documents), and etc... ((((
Am I right understand that all our existing documents in db with old suggestions must be updated?
I understand that this is a big change, however it was a must. We are certainly very sorry to introduce such breaking changes. Here is the issue that is related to that change: #7556. The last post in the issue discusses "migration" a bit.
Other notes in this regard:
I think I could also write instruction for those who process editor data on how their tools can be changed to fit the new data structure.
@kaluginserg We are also working on the solution that will let you get the data with suggestions accepted or rejected straight from the editor. This should be ready in the next iteration (at the end of August). Maybe this feature would also solve some of your problems?
Maybe. We hope)
Currently - trackChanges API is poorly suited for our integrating purposes. And too coupled to the client side. Because of that, currently we have to do lot of extra-work (facades and adapters) for handle track-changes and comments on server side and on client side.
But I am not sure that I right understand what you mean about "get the data with accepted/rejected suggestions"..
This is an off-topic discussion for this issue so let's not follow it further. The feature will simply let you get:
<p>Foo bar baz</p>
Instead of:
<p>Foo <suggestion-start...></suggestion-start>bar<suggestion-end></suggestion-end> baz</p>
Of course, it will apply to all types of suggestion.
Same for discarding suggestions, you will be able to get:
<p>Foo baz</p>
straight from the editor.
This is an off-topic discussion for this issue so let's not follow it further. The feature will simply let you get:
These changes - won't help us. Even I am not sure that we will use this feature. Because we need store all metadata in the markup (we do many server side manipulations with accepting/rejecting - we have parsers for all cke5 generated markup...).
I think I could also write instruction for those who process editor data on how their tools can be changed to fit the new data structure.
@scofalik, @lslowikowska - is there a date, when we can look at these instructions?
I've just finished writing: https://github.com/ckeditor/ckeditor5/issues/7556#issuecomment-668093458
I hope this will be helpful.
Edit: I edited splitMarkerName function (now parseSuggestionName) to make it less confusing.