Preset changes

[mlewand]

Type of report

Task

Provide description of the task

Let's discuss preset changes in 4.10.0.

Out of new plugins very interesting option is emoji plugin. It's small and lightweight.

However we already have a smiley plugin in full preset, which inserts emoticons based on completely different approach (images instead of UTF8 codes).

Let's discuss what are the possibilities from here.

Some options available here are:

• Introduce emoji plugin to standard and full preset and deprecate smiley, meaning that it should be removed from full preset in two or next major release(s).
• Create a brand new set of presets that would feature new plugins.

[mlewand]

AS for the new presets I would like to see something like preset for comment, article, document editor as well as a preset for a minimalistic editor (even smaller than a basic preset).

[Comandeer]

PNGs, used in smiley plugin, are just passe in today's Web, which gives us plenty of ways to use absolutely responsive graphics (picture, img[srcset], SVG, icon fonts…). It's already totally anachronistic plugin and IMO should have been deprecated years ago.

OTOH idea of introducing new presets with more meaningful names also sounds good. So maybe deprecate smiley and introduce new presets?

[engineering-this]

deprecate smiley and introduce new presets?

I second this.

[wwalc]

Whenever thinking about changing presets, keep in mind that this is not only a form of CKEditor distribution that we provide to new users, but also (and maybe even first of all) our "contract" with existing users. For years we let them upgrade CKEditor easily to new versions using still the official CDN and just bumping the version number there, same with GitHub tags etc. If we modify the current presets by removing some plugins then we'd introduce a significant backwards incompatible changes.

With the way how currently CKEditor and ACF works, there might be interesting side-effect consequences of getting rid of the smiley plugin from the full preset, including users losing images in existing articles. This may be due to the fact that smiley itself registers allowedContent: 'img[alt,height,!src,title,width]'. With a mixed combination of removePlugins: image and smileys being dropped from full preset, smileys and images from existing articles would be lost. Having millions of installations, there is a chance for such setups as well.

The last thing that we want is to have our long-time users suffering due to our quick decisions.
Adding new features to presets is not as damaging and dangerous as removing them

---

What I'd prefer to do:

• Think well what kind of setups we'd introduce today, if we were just starting with CKEditor 4 and had no past history of presets.
• Make sure that any eventual proposal has a solid basis and fits a set of reasonable use cases.
• Compare the new presets that we'd eventually introduce with the one that we currently have. There is a chance that some presets like basic/standard may survive. The more new presets we introduce the possibly more work we'll have.
• Verify how much work we'd have to introduce such new presets. It is also crucial for planning, to make sure we will not miss anything important when doing such a change. Keep in mind that changing/adding presets is not just about adding a few files to the ckeditor-presets repository and two additional build configs. Once we launch them a huge amount of resources would have to be updated, including places such as:
  • Documentation (search for all occurrences of basic/standard/full keywords, we mention in many places what is included where)
  • SDK (same as above and introduce new sample for each preset)
  • ckeditor.com website, including download page, presets comparison etc.
  • CKEditor Nightly page
  • possibly some FAQs in zendesk
  • release scripts
  • online builder (which has to be compatible with old presets as there is an URL to rebuild your CKEditor using the newest version of CKEditor)
  • our dedicated Drupal modules to handle CKEditor 4 addons repository
  • our other various scripts, in maaany places we just have 3 hardcoded values

Last but not least, once we introduce new presets we should continue releasing old presets.

Also considering the above, changing presets in 4.10.0 seems like something which is impossible to be done within so short timeframe. This should be rather discussed for 4.11.0.

[mlewand]

@wwalc I like the idea of backward compatibility, presented here.

Adding New Presets & Infrastructure

I'd be standing for gradually adding these new, named, presets to the mix. However the infrastructure should be ready for n additional presets starting from day one. So the amount here, dedicated for the infrastructure will be substantial. But afterwards I'd like it to be limited to some config change, where adding new preset would automatically populate.

Named Presets Compatibility

Second thing is related to compatibility. We treat basic/standard/full presets with extra care when talking about compatibility. But when thinking about our named presets, I'd like to see them being live.

Web changes, content authors were inserting flash animations years ago. They were using images for expressing smileys. Today these techniques changed and most certainly they will evolve further in years from here.

With the above in mind, our named presets should evolve along with the Web.

However each change of the preset should be announced a fair time before the plugin will be actually dropped from the preset (say 2 releases). Additionally together with dropping the plugin from a preset, a information should be added pointing on how to keep the plugin.

Example Scenario

We have a post preset, which matches blog posting, simple intranet docs etc.

Imagine we had a flash plugin there and we decided it's time to drop it.

• We announce the action x releases before it actually happens (blog post, social, other channels included).
• We add a code that detects the case when flash plugin is loaded based on preset (it was not explicitly added via config) - if that's the case a warning is issued in the console, with a link to article that announces this deprecation.
• Article contains a section explaining how to keep the plugin (simply add it in config for example).

[mlewand]

As mentioned we'll need more time for tooling, and plan it out well, moving to next major release.

[mlewand]

Also note that with new presets we could introduce some breaking config settings, for instance we could set the default link protocol to https by default if #2227 gets in.