Prevent enabling a text editor if a text format has one or more FILTER_TYPE_MARKUP_LANGUAGE filters enabled

In the cases where it is sometimes necessary to disable the wysiwyg, filter_autop along with http://drupal.org/project/wysiwyg_linebreaks is something which makes it all a little more useable, so I would as an end user like that sort of functionality to remain in parallel with the use of an editor.

Explain edge case.

In #1933916-2: [meta] How do we want to facilitate enabling of CKEditor for sites upgraded from Drupal 7 to Drupal 8?, I posted a long comment about dealing with auto-p (and could be applied to auto-url also). This issue should move forward since it is important for formats that are truly irreversible. In the other issue, we can consider changing the type of auto-p and auto-url filters from FILTER_TYPE_MARKUP_LANGUAGE to FILTER_TYPE_TRANSFORM_REVERSIBLE, so they wouldn't be affected by this restriction.

Only CKEditor can be disallowed for non-HTML formats. Other editors might be explicitly designed to work with a particular markup format.

That said, CKEditor is definitely able to produce BBCode. I wouldn't be surprised if there is a plugin for it that make it produce Markdown.

Likewise, editors like http://markitup.jaysalvat.com/home/ are capable of producing various markup formats.

Consequently, a HTML vs. no-HTML markup format differentiation doesn't make much sense. We rather have to map individual editors to markup formats, whereas enabling certain editor plugins can enable an editor for a different markup format.

I kind of agree here also. Maybe we need a registry of markup languages to text editors? By default it would be an empty list (or possibly include auto-p/auto-a as compatible with CKEditor, depending on the outcome of #1933916: [meta] How do we want to facilitate enabling of CKEditor for sites upgraded from Drupal 7 to Drupal 8?).

However if we convert auto-p/auto-a to be FILTER_TYPE_TRANSFORM_REVERSIBLE, we end up with no really dangerous/disallowed configurations of the included core filters and editors, mitigating this entire problem somewhat. If a contrib module adds new filters that aren't compatible with a particular WYSIWYG, I would think a notice on the project page or in the README would probably suffice.

I suspect a few people will add either smileys/emoticons or bbcode to atleast some plugins. Either that or a video filter.

People especially coming from other forum software will be used to such features.

Updated issue summary.

What if we just add a warning? Here's a patch that does this.

I think we can allow people to do something foolish. If we do want to add validation still, I think I need it explained to me a bit more.

Whenever >=1 FILTER_TYPE_MARKUP_LANGUAGE-type filter is enabled, we should disallow the enabling of a text editor.

This doesn't make when sense for a workflow in which the editor CKEditor is already selected. I think more often than not, the editor would be selected before enabling filters.

If it is simply when any FILTER_TYPE_MARKUP_LANGUAGE filter is enabled, we prevent the enabling of a text editor, how do we tell if an editor is a text editor? Are all editors text editors? I'm not as familiar with editor plugins.

Here's a screenshot of patch #15:

Here's some validation. It hard codes the two filters in core of type Drupal\filter\Plugin\FilterInterface::TYPE_MARKUP_LANGUAGE, rather than finding any filter where the type is type is Drupal\filter\Plugin\FilterInterface::TYPE_MARKUP_LANGUAGE.

It could be abstracted more, I guess.

I had some trouble with the HTML within the label of the filter_autop: I ended up using htis code: Html::decodeEntities(strip_tags($get_filter_label('filter_autop'))). If there's a better solution, let me know.

Screenshot of #17:

Abstracting it, and adding test coverage. Also, I was able to do away with this: Html::decodeEntities(strip_tags($get_filter_label('filter_autop')))

As far as edge cases, perhaps we should just handle CKEditor in the validation? Or just leave the warning (see #15)?

Trying this again, the last version passed locally, but not on testbot. Trying responseContains instead of pageTextContains.

Also changed the verbiage slightly.

Assigning to myself to fix the test and coding standard issues. I don't know what's going on. It's passing locally, but failing on testbot.

I pulled down the latest, and instead of it showing the first form error, it shows the last. So I guess that's a new change. Updated the test to only set one of the filters at a time, so that we can see the first message. (With both filters turned on, only the second form error displays.) Also, fixed coding standard errors.