CKEditor 5 compatibility

Fix typo

I am unable even to get manually added FA source to appear in CKEditor 5:
https://stackoverflow.com/questions/74762451/ckeditor-5-removes-empty-ta...

Font Awesome icon does not appear in Ckeditor 5 on Drupal 10.0.0 and also it does not appear as available button in toolbar configuration.

fontawesome version: 8.x-2.24

Adding suggestion to implement as an inline widget https://ckeditor.com/docs/ckeditor5/latest/framework/guides/tutorials/im....

I'm seeing the same thing as Morbus IFF.
Even editing source and saving pulls the and classes out of the code which seems odd. Should this be in the core issue tracker since its ckeditor 5 now?

Is there a workaround. Im trying to adjust the filter settings but haven't figured it out yet. Even adding in source would work for now.

Highly detailed update at #3337298-7: [upstream] [GHS] CKEditor 5 removes empty inline elements — discussed this with the CKEditor 5 maintainers! 👍

I started an issue fork and have a mostly working ckeditor5 plugin created on the "ckeditor5" branch of the fork.

It seems to be working for the most part. Icons come through when I switch between a ckeditor4 text format and a ckeditor5 text format.

One thing it is not doing: It simply will not insert the icon when in source mode. It does not remove them when switching source mode on and off, but it will not create them while in source mode.

I am working on adding the svg conversion to the plugin now.

some notes:

• The structure being upcast and downcast has the i or span tag wrapped in a span with the class "fontawesome-icon-inline". I did this to match what was being written to the view by the ckeditor4 plugin. I am not sure if we need to cover cases of icons without this wrapping span.
• I am inserting the span/i tag into the editor view as a RawElement. I did this due to having a lot of issues with inserting a child element with a class. I am then making the icon a widget when downcasting to the editing view so you can manipulate the icon in the editor.
• The Ckeditor5 plugin created here is still using the same Drupal dialog form as the Ckeditor4 plugin. I would like to get it converted over to a Ckeditor5 balloon, but the existing Drupal dialog form works well in the meantime. It would also be great to make the icons editable widgets that can have their attributes modified through the same balloon form.

Before I take a look - I assume you're still working on this & thus the closed merge request?

Yes still working on this

Here is a patch with the Ckeditor5 plugin for people to test.

@dk-massive, Thanks a lot for the MR!

Here is the result of my test:

It is currently the same as for CKE4. Possibility to add icons but when placed not possible to edit it.

Maybe feature to edit may come later.

I went ahead and put up the MR to start getting this reviewed as it does make the module compatible with Ckeditor5. I feel like this is the priority since this module can become a blocker from moving existing sites over to Ckeditor5.

I want to get the dialog form converted to a Ckeditor5 balloon panel similar to how links work, and am happy to help with that. I will have more time later this week to do so.

I've tested this and while it works excellently for inserting new icons, the transition to CKEditor 5 breaks existing content.

Icons which are not wrapped in "fontawesome-icon-inline" span are stripped out of the content on swap to CKEditor 5. To duplicate, you can do something as simple as:
<p><i class="fa-solid fa-house fa-2xl"></i> house</p>

Which works fine in CKEditor 4. When moving to CKEditor 5, the icon is stripped.

Patch from #16 applies; but i still get: The CKEditor 4 button DrupalFontAwesome does not have a known upgrade path.

Patch from #16 applies and works well on Drupal 10.0.9, Fontawesome 8.x-2.25, php 8.1.
It's just the editing and backwards compatibility that's missing.
This issue mentioned by @Daniel.Moberly on comment #21 is a ckeditor5 behavior that strips out empty inline elements and we have the same issue with a different plugin as well.

https://www.drupal.org/project/drupal/issues/3337298

Its an issue that needs to be resolved before this can be committed, unfortunately. We can't add CKEditor 5 functionality that just wipes all existing work for users who already have this module functioning that way on CKEditor 4

I was able to work around this by downcasting fontawesome icons without wrapping spans into elements with wrapping spans. This stopped the icon from being wiped out when switching to ckeditor5, but is modifying the original content. I put this on the branch ckeditor5-alt. It definitely is not a final solution but is there for anyone that absolutely needs to get around this.

This is effectively blocked until Ckeditor 5's General HTML Support package is updated to no longer remove empty elements, but it looks like this will be addressed in the near future. Hopefully. https://github.com/ckeditor/ckeditor5/issues/9888#issuecomment-1594248202

Thanks for all your work on this @dk-massive. We will go on a holding pattern until CKeditor's update is available

It looks like this PR from the CKEditor5 team has this issue fixed as of 5 days ago - https://github.com/ckeditor/ckeditor5/pull/14406 - I haven't tested the latest version and I'm not sure if the latest version of CKEditor5 will now be bundled with Drupal or if something else needs to happen, but I thought I'd bring it to the attention of everyone here that we may be able to proceed with a solid fix for this.

They tagged an alpha release with the update.
https://github.com/ckeditor/ckeditor5/releases/tag/v38.2.0-alpha.1

As soon as 38.2.0 releases we can open an issue with Drupal core to update to it.

#3377562: Update CKEditor 5 to 39.0.0 has been committed to Drupal 10.2.x/11.x, and will soon be committed to 10.1.x. That means development here can continue! 😊

We needed this as a CKEditor 5 plugin so we went ahead and did our own version. The project is CKEditor 5 Icons if anyone is interested.

@timurtripp That looks INCREDIBLE!

This is a fast and native Font Awesome icon picker for CKEditor 5, built using CKEditor 5's modern TypeScript plugin APIs and designed to look like it belongs in the editor.

— https://www.drupal.org/project/ckeditor5_icons

Couldn't agree more!

Looks like the only thing that’s missing is an upgrade path in the form of a CKEditor4To5Upgrade plugin?! 🤓 If that existed, then all sites could smoothly transition the ~46K sites using that module to CKEditor 5!

EDIT: on second thought … https://git.drupalcode.org/project/fontawesome/-/blob/8.x-2.x/src/Plugin... does not have any configuration AFAICT, so that means there literally is nothing to configure! If true, then this would be the entire upgrade path:

/**
 * @CKEditor4To5Upgrade(
 *   id = "ckeditor5_icons",
 *   cke4_buttons = {
 *     "DrupalFontAwesome",
 *   },
 *   cke4_plugin_settings = {},
 *   cke5_plugin_elements_subset_configuration = {}
 * )
 *
 * @internal
 *   Plugin classes are internal.
 */
class FontAwesomeCKEditor5 extends PluginBase implements CKEditor4To5UpgradePluginInterface {

  /**
   * {@inheritdoc}
   */
  public function mapCKEditor4ToolbarButtonToCKEditor5ToolbarItem(string $cke4_button, HTMLRestrictions $text_format_html_restrictions): ?array {
    switch ($cke4_button) {
      case 'DrupalFontAwesome':
        return ['icon'];

      default:
        throw new \OutOfBoundsException();
    }
  }

  /**
   * {@inheritdoc}
   */
  public function mapCKEditor4SettingsToCKEditor5Configuration(string $cke4_plugin_id, array $cke4_plugin_settings): ?array {
    throw new \OutOfBoundsException();
  }

  /**
   * {@inheritdoc}
   */
  public function computeCKEditor5PluginSubsetConfiguration(string $cke5_plugin_id, FilterFormatInterface $text_format): ?array {
    throw new \OutOfBoundsException();
  }

}

Could somebody give that a try? 😊

Does it make sense to move that entire module into Font Awesome Icons as a submodule? Since it relies on Font Awesome anyway, I think it makes the implementation a lot cleaner and we don't have to worry in this situation about folks upgrading to CKEditor 5 and losing data if they are on Core versions prior to 10.1 - folks would have to choose to enable this module independently.

Its a little confusing currently for users looking to change to CKEditor5 to have to pull from a separate module.

Would appreciation thoughts on the idea.

I did the separate module because we only actually need the CKEditor 5 plugin and nothing else – hence why the plugin is self-contained and the dependency is optional if using the built-in metadata and attaching your own library. I didn't take into account CKEditor 4 backward-compatibility concerns as in CKEditor 4 we were using a Shortcode for icons and have a different migration plan for that. I recommended Drupal 10.1.3 or later on the project page but inserting icons works in 9.5 as well (it inserts a   so the element isn't technically empty).

If other folks would like to pitch in to help with CKEditor 4 backward-compatibility I'd certainly welcome that though! Just have no way of testing that on my end.

wow. thank you - stumbled right into your act of kindness! woot.fixed me.

Added a commit that provides the upgrade path. The output here includes me testing entity embed at the same time, but the messages for fontawesome are in there too.

Seems to work with manual testing as well. The SVG/JS was kind of inconsistent, but it doesn't seem like something specific to CK5 - I suspect it's my cruddy laptop.

This is definitely getting close. My upgrade renders some of the icons, but rearranges the content. Some of the icons are lost.

CKEditor prior to upgrade:

<p>test&nbsp;<span class="fontawesome-icon-inline"><i class="fa-solid fa-facebook"></i>&nbsp;</span></p>

<p><i class="fa-solid fa-house fa-2xl"></i> solid<br />
<i class="fa-regular fa-house fa-2xl"></i> regular<br />
<i class="fa-light fa-house fa-2xl"></i> light<br />
<i class="fa-thin fa-house fa-2xl"></i> thin<br />
<i class="fa-duotone fa-house fa-2xl"></i> duotone<br />
<i class="fa-sharp fa-light fa-house fa-2xl"></i> sharp light<br />
<i class="fa-sharp fa-regular fa-house fa-2xl"></i> sharp regular<br />
<i class="fa-sharp fa-solid fa-house fa-2xl"></i> sharp solid<br />
<i class="fa-kit fa-test-custom fa-2xl"></i> custom</p>

CKEditor 5 after upgrade:

<p>
    test&nbsp;<span class="fontawesome-icon-inline"><i class="fa-solid fa-facebook"></i></span>
</p>
<p>
    solid
    <br>
    regular
    <br>
    light
    <br>
    thin
    <br>
    duotone
    <br>
    sharp light
    <br>
    sharp regular
    <br>
    sharp solid
    <br>
    custom<i class="fa-sharp fa-solid fa-house fa-2xl"></i><i class="fa-sharp fa-regular fa-house fa-2xl"></i><i class="fa-sharp fa-light fa-house fa-2xl"></i><i class="fa-regular fa-house fa-2xl"></i><i class="fa-solid fa-house fa-2xl"></i>
</p>

Just curious if anyone is encountering JS performance issues when fontawesome all.js (load assets) and ckeditor5 are loaded. It gets to the point where the page becomes unresponsive if there is fontawesome markup in the editor. I noticed bnjmnm in #37 mentions cruddy laptop performance.

Regarding #42 - yes I'm finding that any old font-awesome code is causing the page to choke and I cannot even edit the page. I was getting the icons to show but then the trying to edit the page locks-up.

But the new patches (#43 and 44) do allow for the FA ckeditor icon to be usable. Seems to be working well on a new page without any existing FA code in it.

It is my experience as well that switching to [source] mode to insert a fontawesome icon into a ckeditor5 edit block, and then switching out of [source] mode causes the entire drupal page to lockup. This bug causes the page to hammer CPU usage, and to use all available memory until the web browser page crashes with an "Error code: RESULT_CODE_HUNG" error.

Below is the test text with a fontawesome icon that I used to crash an entire web browser page during /node/add/{contenttype}

<p><i class="fa-solid fa-envelope-circle-check">&nbsp;</i>&nbsp; this is some text with a fontawesome icon at the left.</p>

Hello, I have the similar issue with fontawesome and CKE5. I am using CDN 6.5.2 version. Drupal 10.1.8. This is blocking one of our important release, unfortunately. Tried to use local fontawesome library, but failed.
When an icon is added CKE5 (eg: <i class="fas fa-camera-retro">). to shows up, but not able edit the page as it locks up!
I applied patch #44 above (CKE5 compatibility). Still edit page locking issue is not going away.

Fontawesome 5.13.1 version (CDN) is working fine with CKE5, but we need to upgrade it to latest version to get the latest icons.

Hello, I have similar issues as #42, #47, #49, #50. I have installed Font Awesome Icons (version 8.x-2.26) on Drupal 10.3.1 with CKE5. The flag button doesn't show up when I checked Text Formats. I manually added <i class> to the allowed list (before doing so, the icon won't show up). I can see the icon after adding the line to source code of a page or block. However, when I tried to edit the page/block, it became totally unresponsive.
Also, I'm unable to enable Font Awesome Iconpicker Widget.

We've been using JuanMitriatti's patches in production for a while now, and they work pretty well. Both are needed to get it to work. However, the fix_inline_icons.patch was introducing an unnecessary non-breaking space after the icons. So, I have re-rolled that patch and am including it here.

Hello, I also encountered issues with CKEditor 5 in Drupal 10. One of the solutions was to manually add the tag to the allowed formats, but the problem was that it would stop responding. So far, this patch shared by my colleague has worked for me

To get some context, why that happens in CKeditor5, please read https://github.com/ckeditor/ckeditor5/issues/16203.

So if I understand this correctly:

• Patches from #44 and #52 are both needed to make this module CKEditor 5 compatible. They seem to work well.
• Switching in and out of source mode will freeze the page, because of a deeper issue with CKEditor 5, which should be solved separately (if at all possible) https://www.drupal.org/project/drupal/issues/3405440

Would it be possible to at least not let the browser become unresponsive?

Tested patches #44 and #52 together, seems to work well. I am not experiencing any performance issues with content that has icons when I toggle source mode, and I am using a pretty slow VM on an old laptop. Posting a patch here that combines both of these patches together.

Created MR#45 that works with the latest version.
It does work for me, however if the button if not added to CKEditor, it kills the whole page still.

This all seems to work well on a new site. But when I upgraded an existing site using fontawesome icons from CKE4 it blows up. All content in the body field is removed and I get this console error:

CKEditorError: Cannot read properties of null (reading 'getAttribute')

The old CKE4 content looks like this:

<span class="fontawesome-icon-inline"></span><span class="fa-lightbulb fas"></span>

I think the issue is with the upcast function:

conversion.for('upcast').elementToElement({
      view: {
        name: 'span',
        classes: 'fontawesome-icon-inline',
      },
      model: (viewElement, { writer }) => {
        const childElement = viewElement.getChild(0);
        const fontAwesomeIconInline = writer.createElement('fontAwesomeIconInline', childElement.getAttributes());
        writer.setAttribute('data-tag', childElement.name, fontAwesomeIconInline);
        return fontAwesomeIconInline;
      }
    });

viewElement.getChild(0) is undefined if the <span class="fontawesome-icon-inline"></span> is empty (i.e., it has no child elements). Then calling childElement.getAttributes() on an undefined object throws the error.

Looking into a fix for this now.

Ok pushed up a small improvement to the upcast function. Now when it finds the old CKE4 markup it automatically converts it to the nested markup from the CKE5 plugin and no more issues.

I'm having issues with Duotone Icons.

The structure added is:

<span class="fontawesome-icon-inline">
  <span class="fa-duotone fa-house" aria-hidden="true">&nbsp;</span>
</span>

If I jump to source code and try removing the &nbsp manually, when I exit Source or when I save the content, the &nbsp is added back.

If I remove the wrapper <span class="fontawesome-icon-inline"> then the duotone icon works properly.

If I try to use <i> instead of <span>, this is the code, and I still have the same issue:

  <span class="fontawesome-icon-inline">
    <i class="fa-duotone fa-house">&nbsp;</i>
  </span>

I have tested this patch and am seeing issues with existing content:

<span class="fa fa-check text-success"></span> My demonstration text.

Becomes:

<span class="fa-check text-success"><span class="fontawesome-icon-inline"><span class="fa fa-check text-success">&nbsp;</span></span></span>My demonstration text.

Two issues with this, the first is the extra span and the second is the removal of the space before the text.

I am also seeing an issue where if I enable fontawesome with the default settings and configure ck5 source editing to allow , then edit a node and add a fontawesome icon manually in the source code editor then switch back out of source code editing my entire browser hangs. I tried installing this patch and the same thing happens when editing the node and switching in and out of source mode. It happens in both Chrome and Firefox. Has anyone else seen this?

Pushed a fix to the MR, to fix failing kernel test; make provider() method static.

So I have tested this with the latest 3.0 branch and it appears to be working for me in terms of no hang-ups (using Firefox) and it allows the previous fontawesome icons to appear and be editable via source but it appears to be doubling the tags when I edit the page as referenced in #70 this results in icons that have fa-2x being applied twice which makes them twice as large.

These were manually added icons so I suspect what's happening is in comment #25 "I was able to work around this by downcasting fontawesome icons without wrapping spans into elements with wrapping spans." - it does this downcasting but I suspect this is now creating these in additional to the original thus doubling them.

I don't know much about the ins and outs of CKEditor5 javascript so I am not sure I'll be able to fix this but hopefully someone can at some point.