Quantcast
Channel: Issues for Drupal core
Viewing all articles
Browse latest Browse all 314008

[meta] How do we want to facilitate enabling of CKEditor for sites upgraded from Drupal 7 to Drupal 8?

$
0
0

Problem/Motivation

Over at #1911884: Enable CKEditor in the Standard install profile, the Standard install profile's "Filtered HTML" format is being split into two:

  1. "Restricted HTML" for anonymous users. The only change wrt "Filtered HTML" is the enabling of setting "rel=nofollow" on all links.
  2. "Basic HTML" for authenticated users. The changes wrt "Filtered HTML": disabling of filter_autop and filter_url filters, allowing of <img> tags, enabling of the filter_html_image_secure filter.

And over at #1933914: Enable CKEditor in the Standard install profile's "Full HTML" text format, we're working to enable CKEditor by default for the "Full HTML" text format as well.

At the same time, over at #1933896: Prevent enabling a text editor if a text format has one or more FILTER_TYPE_MARKUP_LANGUAGE filters enabled, we're working on preventing users from enabling text editors in situations where it should be disallowed (e.g. when using Markdown).

However, one of the not-really-expected situations where a text editor is disallowed by the same reasoning, is in Drupal 7's default "Filtered HTML" and "Full HTML" text formats, both of which use both filter_autop and filter_url filters. This means that sites upgrading from Drupal 7 to Drupal 8 (meaning that they have content using those text formats, which the upgrade process won't & can't touch) will not be able to just turn CKEditor on and be done with it.

(If it doesn't make sense to you that using filter_autop and filter_url precludes you from using CKEditor, then please read #1911884: Enable CKEditor in the Standard install profile and #1933896: Prevent enabling a text editor if a text format has one or more FILTER_TYPE_MARKUP_LANGUAGE filters enabled FIRST.)

Proposed resolution

In order to use CKEditor, Drupal 8 sites upgraded from Drupal 7 would have to modify all existing content to stop using the filter_autop and filter_url filters. It's easy enough to write code that does this upgrading: a Queue/Batch API implementation that goes over every piece of content ever created, applies _filter_autop() and _filter_url() and saves it back.

However, the problem lies not with "typical" content like nodes etc., but with content that is using text formats that lives somewhere Drupal/we can't know about — after all, contrib modules are allowed to do crazy things.

Finally: the secondary question is who should provide this "upgrade existing content to migrate away from using filter_autop and filter_url" functionality: core or a contrib module?

Remaining tasks

  1. Get feedback on "how to do the upgrading".
  2. Get feedback on "who should provide the upgrading"?
  3. Implement.

User interface changes

TBD (likely none).

API changes

TBD (likely none).


Viewing all articles
Browse latest Browse all 314008

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>