DEP Upgrade frontend build stack

[GuySartorelli]

See silverstripe/silverstripe-admin#1389 for a wider discussion on most of the changes

Parent issue

• https://github.com/silverstripeltd/product-issues/issues/644

[GuySartorelli]

mime isn't used

[GuySartorelli]

Neither jest nor bootstrap is used

[GuySartorelli]

Fixes error Typo in static class property declaration react/no-typos (see the docs on this rule)

[GuySartorelli]

This module includes a tinymce4 fontawesome4 plugin in a thirdparty directory. This is wildly outdated, and the source code on github isn't much better.
I've found a few tinymce5 plugins that provide similar functionality but nothing for tinymce 6.

We'll need to either:

1. Fork an existing tinymce fontawesome plugin and update it to be compatible with tinymce 6
   • not the one in thirdparty 'cause that's way too old now - but there are some that are compatible with tinymce 5 which might be easy-ish to upgrade
2. Make our own tinymce fontawesome plugin and maintain it
3. Ditch the fontawesome tinymce plugin for this module

We should also add behat tests for all of the js functionality in this module.

[GuySartorelli]

HtmlEditorConfig doesn't actually have some of the methods that are being called - this is explicitly for tinymce configuration.

[GuySartorelli]

It looks like whatever controls the underlying popover has changed its markup - this is now a div below the .color-picker-field-popover div. If we keep it as it was, there is 380px of whitespace to the right of the form any time you open one of the dropdowns.

[maxime-rainville]

This module includes a tinymce4 fontawesome4 plugin in a thirdparty directory. This is wildly outdated, and the source code on github isn't much better.

My assumption here is that whoever includes FA icons in a WYSIWYG probably use them effectively as emojis. When FA first came on the scene, Emojis were not as widely supported as they are today. That's probably why no one bothered porting those those FA plugins to work with TinyMCE6.

TinyMCE6 has a free Emoticon plugin.

My suggested approach at this stage is:

• Remove the FA plugin on CMS6.
• Maybe add some extra logic just to make sure that existing FA icon still show in the HTMLEditor and in the front end.
• Maybe enable the Emoticon plugin in the CWP Agency Extension module.

[GuySartorelli]

I will remove the legacy font-awesome plugin.

I will not enable the emoticon plugin, as I see that as being for a fundamentally different use-case (there aren't even any emoticons/emojis in font-awesome - see the icons in the icons list compared with the tinymce emoji - there's not a lot of crossover other than I guess the objects category)
I will call it out as a potential alternative that developers can enable if they think it is suitable for their project.

There is an existing CWP_AGENCY_DISABLE_FONTAWESOME_PLUGIN environment variable which, if set, disables the plugin. I'm going to flip this on its head and replace it with CWP_AGENCY_ENABLE_FONTAWESOME_STYLES.
If the new variable is set, then the extended_valid_elements configuration and font awesome css (from a cdn) will be added to the tinymce config like it used to be. If that is not set, then no font awesome configuration or css will be added at all.

You already had to add css on the front-end separately, so that will not be affected. Projects using this module which wish to keep any existing font-awesome icons in their content will need to set CWP_AGENCY_ENABLE_FONTAWESOME_STYLES to true in their environment variables to see the icons in the CMS WYSIWYG, and to ensure the icons are retained when saving.

Note that is would not be feasible to set this to a yaml config since it requires calling methods on the TinyMCEConfig in _config.php, which happens before some yaml config is set. If there are any projects which cannot set environment variables, they can set the appropriate config and inject the css themselves for their project, which is trivial.

I will call all of this out in the changelog.

[emteknetnz]

Tested locally