Add support for a raw text formatter

This sounds a feature request and has to go into d8 first and be backported

Rerolled for the new plugin system + added tests.

I'm not sure whether we'll ever get this in core because of potential security issues here - although it's easy to configure your site wrong with text formats too.
It's a formatter I probably write for every project though, so it would be handy to be in core :)

Woops, empty patch.

Hmm, a 'raw' formatter in core that you can "simply" select and give up security sounds like a pushing a loaded gun in the hands of unaware users...

The use cases mentioned in the OP are, well, legit, but sound edge case enough that shipping this in core sounds questionable given the security impact - besides, D8 will have other solutions for data export than views spitting formatter-based output.

Bumping over to sun to get his opinion.

+class TextRawFormatter extends FormatterBase {
...
+  public function viewElements(EntityInterface $entity, $langcode, array $items) {
...
+      $elements[$delta] = array('#markup' => $item['value']);

Oy. ;) So yeah... this is kind of The Ultimate Way To Hose Your Site™ :)

Based on technical grounds only, this formatter would have to be limited to text fields that do not have text processing enabled. In other words: If there is a text format assigned to a text field value, then there must not be a way to output the raw user input without filtering.

I don't know whether Field API is capable of doing that; i.e., limiting a formatter to sub-variants of field types.

I'm also not sure whether that's all that would be required. I think we'd additionally need to introduce security warnings in a couple of places, so as to inform the user that "Howdy, this is not a good idea, because... Press the Confirm button if you are really sure you want to do this, or Cancel to reset to a previous/safe configuration."

Now on to the logical side...

I don't think I understand the use-case. ;) You surely do not want to render any user input without escaping/sanitization/filtering potential XSS and CSRF, right?

I can only assume that the actual use-cases boil down to text fields that are only exposed to site administrators/builders, which in turn means that you believe that you're safe and exempt from any attacks, because, well, you entered that HTML yourself. Is that a fair understanding? :)

Let's make sure to clarify the actual use-case for this first.

But in general, if aforementioned assumption is the case, then I would actually recommend to forget about the entire text field/formatter integration, and instead, introduce an entirely new HTML field type. That makes clear that the user input is expected to be raw HTML and the field's entire purpose is to output raw HTML. Also no danger of unintentionally outputting user input that ought to be filtered. And access to the field could even be controlled through specialized access permissions. Would that make sense?

Thanks for notifying.

@sun : regarding use case, see the OP

Enterprise users using Drupal to export data to other services via Views and other contrib modules might need their content in it's original form (as they entered it), but will find that all their content is being escaped

This is IMO the only valid use case, and basically in #7 my take on that was :
- Too edge case for core, given the security implications for 99% unsavvy users
- D8 will have better tools for data export

So hm... pure export.

If we were able to differentiate between the final output format of a rendered entity or view, and thus, if we could be sure that the raw formatter wouldn't be used on an HTML page, but only when rendering into XML/RSS, JSON, etc.pp., then I could see this working for core. But I guess that's a very long shot...

We have no way to qualify view modes (HTML, export-only), and we have no way to force a formatter to be available on some view modes only, so yeah, the premises in #11 look out of reach.

I guess that's a "won't fix", then... @Swentel, what do you think ?

Yeah, this is contrib material :)

Pinged the fine folks in #1819760: Add a REST export display plugin and serializer integration., which aims at getting a JSON (non JSON-LD) output for views.

I found out that you can use hook_field_formatter_info() + hook_field_formatter_view() to support field formatters in Views.