Enable CKEditor in the Standard install profile (for the "Filtered HTML" and "Full HTML" text formats)

Problem/Motivation

As of #1890502: WYSIWYG: Add CKEditor module to core, we have a WYSIWYG editor in Drupal core. But: the module is not yet enabled by default, nor is CKEditor associated yet with Filtered/Full HTML.

Sounds simple, right?

The problem is that right now, both the "Filtered HTML" and "Full HTML" text formats are using the filter_autop and filter_url filters. The consequence is that having these enabled while at the same time using CKEditor causes mismatches between what the editor sees in the WYSIWYG editor versus what the reader sees in the (filtered) end result!

Let me clarify:

1. filter_url:
   1. create or edit an article node with either the "Filtered HTML" or "Full HTML" text format
   2. paste this text:
      
      http://drupal.org
      into the body field
   3. save (note that we did not turn this into a link!)
   4. view: now this has become a link, because of filter_url:
      
      <a href="http://drupal.org">http://drupal.org</a>
   5. edit again: not a link → a persistent mismatch!

   Now, this is the weakest case of the two; but note that there is a persistent mismatch between what it looks like in CKEditor and what it looks like to the end-user/reader.

2. filter_autop:
   1. create or edit an article node with either the "Filtered HTML" or "Full HTML" text format
   2. switch CKEditor to "Source mode" (where you can edit the HTML directly) and paste this text:
      
      <p>Paragraph 1.</p><p>Paragraph 2.</p>
      into the body field
   3. go out of "Source mode"— you will now see two paragraphs, as expected
   4. view: now our content consists of a single paragraph instead of two! Look at the source and you will see this:
      
      <p>Paragraph 1.Paragraph 2.</p>
   5. edit again: two paragraphs again → another persistent mismatch!

   Again a persistent mismatch, but this time with severe consequences: depending on the whitespace in the HTML, the (filtered) end result may be perceived as corrupted! Only if one were to inject the whitespace (newlines: \n AKA U+000A LINE FEED (LF)) expected by filter_autop, the intended HTML would also be served to the end-user/reader after filtering.
   Note that this is in conflict with the HTML spec, which says that whitespace outside of text nodes ("inter-element whitespace") doesn't matter:

   The space characters, for the purposes of this specification, are U+0020 SPACE, U+0009 CHARACTER TABULATION (tab), U+000A LINE FEED (LF), U+000C FORM FEED (FF), and U+000D CARRIAGE RETURN (CR).

   http://dev.w3.org/html5/spec-LC/common-microsyntaxes.html#space-character

   The space characters are always allowed between elements. User agents represent these characters between elements in the source markup as text nodes in the DOM. Empty text nodes and text nodes consisting of just sequences of those characters are considered inter-element whitespace.

   Inter-element whitespace, comment nodes, and processing instruction nodes must be ignored when establishing whether an element's contents match the element's content model or not, and must be ignored when following algorithms that define document and element semantics.

   http://dev.w3.org/html5/spec-LC/content-models.html#content-models; emphasis mine.

   (It's very well possible that I'm quoting the wrong part of the HTML spec — that thing is a huge maze, but the point still stands.)

Proposed resolution

• Non-controversial parts:
  • Enable editor.module + ckeditor.module by default.
  • Associate CKEditor by default with the Filtered HTML and Full HTML text formats.
• Controversial parts:
  • Remove the filter_autop and filter_url filters from both the "Filtered HTML" and "Full HTML" text formats.
  • Provide an upgrade path that automatically updates the "old""Filtered HTML" and "Full HTML" content from Drupal 7 to Drupal 8. Detect if the format is modified, and if that's the case, then don't apply the upgrade path, and disable CKEditor for each modified format.

For keeping the allowed tags in sync with the CKEditor toolbar configuration: that shouldn't be covered in this issue, but over at #1894644: Unidirectional editor configuration -> filter settings syncing.

Remaining tasks

The controversial parts :)

User interface changes

The UI will change insofar that having a WYSIWYG editor enabled by default will "change" the UI — no new or modified UIs though.

API changes

None.

Original report by Wim Leers

From #1890502: WYSIWYG: Add CKEditor module to core, first listed follow-up:

Enable the CKEditor module by default in the standard install profile, enable it as the default Text Editor for the Filtered HTML and Full HTML text formats, provide default configurations of CKEditor for both of those text formats, and potentially modify the filters/filter settings of those text formats.