Deprecate "Text (Formatted)"

Because CKEditor doesn't work for input[type=text], only for textarea.

It doesn't make sense for a tiny rectangular box with only one line of space to write huge piles of formatted text with.

And yes, this is highly confusing :( But not for CKEditor to fix.

So, actually, let's move this there.

Should we offer this at all? This type of field? I guess it makes some sense, if you want to format something like your title?

Should we offer this at all? This type of field?

I think not.

I guess it makes some sense, if you want to format something like your title?

If it's HTML, it can be any HTML anyway. So it feels like the wrong solution even for that.

Yup, deleting this field would be a D9 thing though?

Yes. But we can make it hidden, so that no new sites can start using this confusing field type.

Yeah, this is not a useful combination.

Don't we have this trick where we can hide it by default for new installs and have upgrade/update routines check for it being used and then enable it for existing sites?

🙏

I don't think the issue title as is is a good idea. I agree with the "symptom" of the issue that because CKEditor does not work for text input (only textarea) that the current UI is confusing or misleading.

However, I disagree with the proposed solution. The problem is that due to the history of the field system, we have modelled our field types after the form widgets they can be edited with instead of considering the underlying data structure. That is why we have the distinction between "Text (formatted)" and "Text (formatted, long)" in the first place (and the same goes for the "String" field types). Both fields actually store the same data structure, so they should not be two different field types. (The fact that they use different database column types for the text is a) an implementation detail and b) based on legacy restrictions of ancient database versions so are fairly arbitrary nowadays, so should not be relevant for this decision.) We actually have an issue for removing that distinction but I can't find it right now.

And then for the scope of this issue we can still decide that we don't want to allow people to populate formatted text fields via text inputs. We already have mechanisms in place to hide widgets under certain conditions, and possibly we need to improve those mechanisms if we come up with new use-cases here.

Thinking about it a bit more:

It doesn't make sense for a tiny rectangular box with only one line of space to write huge piles of formatted text with.

Actually I use it like that a lot. I need italic and bold (and a device specific linebreak) on title fields, and need a CKEditor for that.

Switching every text field to longtext can have an impact on performance as the db storage is different, therefore removing "Text (formatted)" field might not be a good idea.
DB storage:
Text (formatted) is a VARCHAR(n)
Text (formatted, long) is LONGTEXT

Can "Text (formatted)" field have an additional widget?
Looks like I need to check the textarea_widget_for_text module. Seems too easy..

We would need to deprecate this first in order to remove it. So moving back to a minor branch. (It's likely to end up filed against 9.1.x a couple bulk updates from now, but putting filed in 8.8.x is how we get to that branch.) Thanks!

I'm going to strongly agree with Pasqualle in #19 that there IS a use case for having a wysiwyg editor for shorter text input fields. In my case, I need limited formatting for a title field that includes <em> and the ability to add special symbols (smart quotes, non-English characters, etc.), and the CKEditor WYSIWYG would provide non-technical content editors with the ability to do this without having to know HTML or entity codes. Because this is a short formatted text field, the "Text (formatted)" field type sounds a LOT more appropriate than either "Text (formatted, long)" or "Text (formatted, long, with summary)". It's the obvious choice for this use case, but it is NOT obvious in any of the UI that this option does not provide for the CKEditor toolbar. It just looks broken when you add a text formatter with a configured CKEditor to a "Text (formatted)" field.

The initial assertion at the top of this issue that CKEditor can not be used with input[type=text] is not (no longer?) correct. You can replace any DOM object with CKEditor. In CKE4 although it is "recommended" for only textarea and div elements, there is a proof-of-concept that it's possible with an input[type=text], and CKE5 seems to be even more DOM-agnostic:

• CKEditor 4: https://ckeditor.com/docs/ckeditor4/latest/api/CKEDITOR.html#method-replace
• CKEditor 5: https://ckeditor.com/docs/ckeditor5/latest/api/module_editor-classic_cla...
• Proof-of-concept in CKE4: https://stackoverflow.com/questions/48007539/how-to-add-an-input-type-te... https://codepen.io/f1ames/pen/qpjKxq

Since the "Text (formatted)" field CAN handle non-text HTML, etc., just fine in input[type=text] via a properly formatted text formatter, there is no ideological reason to not also provide the same toolbar that is available to the other formattable-text fields. The main technical challenge appears to be that Drupal's implementation has baked textarea in pretty heavily, which may make expanding it to even only one other DOM element a challenge.

If this field is deprecated, then the other formattable text fields should be re-named to remove the "long" descriptor, which would be both confusing and inaccurate.

It would also be REALLY helpful to have some sort of documentation for all the default field types: how the data are formatted, what they can and can not be used for, etc. Especially where similarly-named field types have different storage configurations that impact their capabilities. I looked all over and found nothing but one stackoverflow question that provided incomplete details on text formats. I'm glad that I finally found this issue, after way too much searching for information about why the CKEditor toolbar was not showing up where I expected it to.

One more follow up on how Drupal 8 sets up site builders to fail (as it did for me):

1. The "Text formats and editors" form for adding/editing a text format happily allows you to choose CKEditor and configure a toolbar with NO alerts/warnings that it may not be available on certain formatted text fields (including default ones).
2. The entity "add field" UI does not provide any information (or links to information) on the differences between field types: you just get to choose a field type to associate with the new field.
3. Allowed Formats, if enabled, does not flag any of the available CKEditor-using text formatters as inappropriate.
4. There is a documentation page on core field types, with links, but absolutely no information here on how they're different, even in a general sense: https://www.drupal.org/docs/8/api/entity-api/fieldtypes-fieldwidgets-and-fieldformatters
5. (Note that the above page lists fields by machine name, whereas the field selection UI presented to site builders is the field label. It's up to the user to figure out that "text" maps to "Text (formatted)".)
6. The link on the page above to the various fields in the API points to a page that is devoid of any useful information: https://api.drupal.org/api/drupal/core%21modules%21text%21src%21Plugin%21Field%21FieldType%21TextItem.php/8.3.x
7. And the page linked from that to the class definition is equally lacking in information that might help someone determine how the field is expected to be used: https://api.drupal.org/api/drupal/core%21modules%21text%21src%21Plugin%21Field%21FieldType%21TextItem.php/class/TextItem/8.3.x
8. When you view a form where you expect to see your CKEditor toolbar above a formatted text field, the output is incomplete and looks like something is broken. There is no indication of what went wrong: Did you miss a crucial configuration? Is this a bug in CKEditor? Or in your particular site's setup? You're going to spend a lot of time trying to debug what appears to be an error before you think "Maybe this is how it's supposed to be."
9. More on the above point: https://drupal.stackexchange.com/questions/254931/how-to-use-ckeditor-layout-on-textfield-input-drupal-8 The outline that usually surrounds the form item is continuous below the form element for the text formatter details, but just cuts off where normally it would continue above to outline the toolbar. It LOOKS like a rendering error, not expected behavior for a formattable text field that you've properly configured with a text formatter. (The red outline in the image on this page is NOT part of Drupal, but the poster's addition to highlight the problem.)

As long as the "Text (formatted)" field type remains available, but remains incompatible with the CKEditor toolbar, there needs to be some information communicated to the site builder that the text formatter's behavior and appearance will be different from the other formatted text fields.

Yes, it should be definitely written somewhere: if you want to use CKEditor on "Text (formatted)" field, then use the textarea_widget_for_text module.

I am wondering why it is not mentioned on the project page.

Thanks, Pasqualle! I just finished trying out the textarea_widget_for_text module and I can confirm that it just works, and is way too easy. Just switch the text field to the new textarea widget and the CKEditor toolbar comes along for the ride.

Looking at the module's code, it would be super easy to accommodate the "Text (formatted)" field in the existing CKEditor implementation if you simply added a condition that implements hook_field_widget_info_alter() to any input[type=text] field configured to use a text formatter for which CKEditor has been implemented. (No need to change anything if the text formatter for the field does NOT use CKEditor.) This would make the field work automatically and consistently like the other formatted text fields, without needing extra documentation pointing to the helper module or explaining why "Text (formatted)" is special.

At the moment, it looks like the CKEditor does not respect the form widgets' height configurations for ANY of the formatted text fields. That would be a very handy fix to implement as well in conjunction with this.

[Edit to add]
I just tried the CKEditorHeight module in conjunction with Textarea widget for text fields and they work great together to handle both the initial problem and my comment about CKEditor height configuration. Both would be great additions to core for making text fields and their configuration consistent and intuitive.

I'd like to add to Pasqualle and DaleTrexel's comments. We also have a need to use "Text (formatted)" restricted to italic and bold - for our scientific publication libraries. Textarea widget for text fields. Also works great. Would also add CKEditor height options that works to our wish list. "Text (formatted") seems like the appropriate choice in this case.

"Description" fields also make perfect sense to use with Text (Formatted) because I want to enforce a 100-300 maximum character length, but the fields may contain HTML. I don't agree about deprecating the field type, I'd rather be able to use the textarea widgets on it. I think we should take https://www.drupal.org/project/textarea_widget_for_text and make a core patch out of it.

I opened #3344041: Allow textarea widgets to be used for text (formatted) fields to propose allow the textarea fields for these field types in core.

Know we are planning to deprecate #3427095: [Meta] Deprecate text_with_summary do we want to really deprecate both?

I'm also against deprecating this field as I'm also using the textarea widget for text fields module for the exact same use cases: for adding strong, italics, exponents, etc. in title fields, SDC props, and other short text fields where it doesn't make sense for a full textarea/longtext field. I see I commented in the other issue 2 years ago, and just want to say it still works very well. I have custom text formats explicitly limiting the number of buttons that are used in the CKEditor for these fields.

Agree

Text_with_summary is going to be removed so think this needs to remain.