coremedia / ckeditor-plugins Goto Github PK

Describe the bug

When image blobs are referenced in data, like:

<img alt="Alternative Text: Red Image" xlink:href="content/900#properties.data"/>

They are not display anymore since CKEditor Plugins Release 5.0.0. In example data (for example "Various Images" you will see a broken image instead)

To Reproduce

Steps to reproduce the behavior:

1. Open Example Application
2. Select "Various Images" from example data.

Expected Behavior

The image is loaded from service and displayed within CKEditor.

Actual Behavior

The image is shown as a broken image with "HTML object" tag rendered on top.

Environment (please complete the following information):

• OS: iOS, Windows
• Browser: Chrome, Firefox
• CKEditor Version: 34.0.0
• CoreMedia's CKEditor Plugins Version: 5.0.0

Additional context

• Data-Processing correctly applies a dummy image (required, as blob data are retrieved lazily from backend).

• Image in Model is represented as:

  <htmlImg
    htmlAttributes="{attributes:{alt:"Alternative Text: Red Image", "data-xlink-href": "content/900#properties.data"}}"
    htmlContent="">
  </htmlImg>
  

  Thus, it is the GHS Plugin which kicks in here, and handles an unknown "img" element.

• Expectation is, that it is related to recent CKEditor Update, introduced with:

  • #64

Describe the bug

If there is just one paragraph within a table data cell <td>, it is removed within CKEditor processing, which reflects this architectural decision:

The table feature allows for creating block content (like paragraphs, lists, headings, etc.) inside table cells. However, if a table cell contains just one paragraph and this paragraph has no special attributes (like text alignment), the cell content is considered “inline” and the paragraph is not rendered.

(See Tables - CKEditor 5 Documentation).

While this may be desirable, all CoreMedia RichText created with CKEditor 4 comes with paragraphs (always). Thus: While CoreMedia RichText DTD considers singleton paragraphs as valid just as just plain characters within <td>, processing in CKEditor may remove this <p>. This may cause subtle different results in rendering CoreMedia RichText later on, thus, it is considered a bug.

To Reproduce

Steps to reproduce the behavior:

1. Go to Example App.

2. Set the following data in source editing:

   <?xml version="1.0" encoding="utf-8"?>
   <div xmlns="http://www.coremedia.com/2003/richtext-1.0"><table><tbody><tr><td><p>Lorem</p></td></tr></tbody></table></div>

3. Store Data

4. Reopen source editing.

Expected Behavior

Paragraph should be kept as is (the same: if there is none, no paragraph should be added).

Actual Behavior

Singleton paragraph is always removed according to the requirement stated above.

Possible Workaround

On data-processing add some attribute to the paragraph, so that it isn't removed as being obsolete.

Environment (please complete the following information):

• OS: Windows 10
• Browser: Chrome
• Browser Version: 99.0
• CKEditor Version: 32.0.0
• CoreMedia's CKEditor Plugins Version: 4.0.1

📝 Describe the Bug

A clear and concise description of what the bug is.

👣 Reproduction Steps

Steps to reproduce the behavior:

1. In source editing paste:

   <?xml version="1.0" encoding="utf-8"?>
   <div xmlns="http://www.coremedia.com/2003/richtext-1.0">
       <p>
           Hello <span class="strike underline">World</span>!
       </p>
   </div>

   where underline and strike refer to the reserved classes to be mapped to <u> and <s> respectively.

2. Switch to editing mode.

✔ Expected Result

Ideally, editing view should contain for the relevant part:

<p>
  Hello <s><u>World</u></s>!
</p>

❌ Actual Result

Editing view only keeps the "strike" state:

<p>
  Hello <s>World</s>!
</p>

No traces left for "underline".

📃 Environment

• OS: Windows
• Browser: Chrome
• Browser Version: 105.0.5195.128
• CKEditor Version: 35.1.0
• CoreMedia's CKEditor Plugins Version: 9.1.0
• Installed CKEditor Plugins: CoreMedia RichText

If you'd like to see this fixed sooner, add a 👍 reaction to this post.

📝 Describe the Bug

Documentation states, that this plugin is not part of the Studio Essentials Plugin:

This is wrong. It is one of the two important plugins integrated into Studio Essentials Plugin.

📃 Environment

• CoreMedia's CKEditor Plugins Version: 9.0.1

If you'd like to see this fixed sooner, add a 👍 reaction to this post.

If you try to store a text such as:

Lorem <Ipsum> Dolor

You will end up with the following being stored as data:

Lorem Dolor

🔎 Analysis

As it seems, this behavior is the result of:

Taken from Stack Overflow:

• javascript - HTML Entity Decode - Stack Overflow

Even the original fiddle has issues with texts such as Hello <nice> World and will end up as Hello World.

🩹 Fix?

• Find a new way of resolving entities, or
• don't resolve them, but make the entities available an CoreMedia RichText known to the whole processing.

Describe the bug

When dropping two (or more links) one after another at the end of the text, both links will be merged into one having only one target.

To Reproduce

Steps to reproduce the behavior:

1. Open Example App
2. Empty Content (easier to reproduce)
3. Open Drag Examples
4. Drag first content
5. Drag second content "at the end", thus, the mouse cursor far to the right
6. See error

Expected Behavior

A second link is created with its text added right behind the previous link. Both parts have a different link target.

Actual Behavior

Text of the second link is written, but the attributes, especially the link's target, is only taken from the first dropped link.

Environment (please complete the following information):

• OS: Windows 10
• Browser: Chrome
• Browser Version: 99.0
• CKEditor Version: 32.0.0
• Plugins Version: 4.0.0

Describe the bug

When you drag and drop several contents into CKEditor, the editing position will be set right after the first dropped (and loaded) content.

To Reproduce

Steps to reproduce the behavior:

1. Open Example App
2. Empty Editor
3. From Drag Examples, choose one with various contents (like Slow/Fast/Slow)
4. See error

Expected Behavior

Contents are added line by line and the cursor is either in a new line after all contents dropped, or right at the end of the last content (typing shall not continue link, but just write text).

Actual Behavior

Editing cursor appears behind first loaded content (in case of Slow/Fast/Slow right behind the fast content).

Environment (please complete the following information):

• OS: Windows 10
• Browser: Chrome
• Browser Version: 99.0
• CKEditor Version: 32.0.0
• CoreMedia's CKEditor Plugins Version: 4.0.0

Describe the bug

When editing an existing content-link and deciding to remove the link in form view, the raw model value content:42 is displayed in the link form view:

To Reproduce

Steps to reproduce the behavior:

1. Open Example-App
2. Open Content Link Examples
3. Start Editing a Content Link Target
4. Press "Remove" (aka Cancel) button in link form view.

Expected Behavior

Input field is completely empty afterwards.

Actual Behavior

The displayed link is removed and replaced by its raw model value: content:42.

Environment (please complete the following information):

• OS: Windows
• Browser: Chrome
• Browser Version: 104.0.5112.102
• CKEditor Version: 34.2.0
• CoreMedia's CKEditor Plugins Version: 8.0.0

When transforming a <br/> from CoreMedia RichText to view, the <br/> is essentially duplicated here:

The debugging output will reveal, that the BasicHtmlWriter by CKEditor transforms the <br/> in the document fragment to <br></br> which in subsequent processing is transformed to <br/><br/>.

This may be a CKEditor issue, or we need to fix the serialization in some way. As a patch, we may want to just handle these occurrences specifically by search & replace. Or, we should consider using for example the XMLSerializer as we do in corresponding tests.

Note, that this also affects the current approach for General RichText Support (GRS) based on CKEditor's General HTML Support (GHS), as any class attribute is removed in this processing: #35.