Switch revision log views fields to use 'field' formatter

Mh, I wrote that in some other issue as well, but I think we don't need that, because we have auto-escaping these days ... It would be great if someone with more knowledge about the auto-escaping system could comment.

Yes, pretty much.

So we can mark this issue as fixed.

OK then, so lets just remove that stuff..

That won't work, we still use that in aggregator! So I think it makes sense to just remove this in one issue if we're going to? Otherwise we will need another follow up after the aggregator issue just to remove the handler?

Fair, everything relies on twig for security anyway, so people using custom template engines are pretty much lost already, if you ask me.

Let's break the dependency on aggregators Xss field handler, it doesn't really need the one we're removing at all. We can work out somewhere else if we really need to keep that one.

+1

+++ b/core/modules/aggregator/src/Plugin/views/field/Xss.php
@@ -16,13 +17,13 @@
-class Xss extends XssBase {
+class Xss extends FieldPluginBase {

Is this tested now?

Same as before, tested briefly in Drupal\aggregator\Tests\Views\IntegrationTest.

The docs in core/modules/aggregator/src/Plugin/views/field/Xss.php got garbled (indentation) in this patch. Also I don't understand why this patch is touching that plugin at all, since there's a separate issue for aggregator's use of XSS filters? Unless you want to close that one as a duplicate of this one and take care of both of them here?

So to be clear, there is 'xss' as well as 'aggregator_xss' ... for the reason that there are fields which need a special xss checking.

This issue removes the XSS plugin itself, ... BUT the aggregator_xss plugin extended from it, so we had to adapt the aggregator_xss module to keep working.

I'm also confused as to why you are removing the "xss" filter from Views. This is a filter for generic non-entity database table data, and it seems like it could be useful to keep it around

This is something to discuss in general ... and we came to the conclusion that we rely more and more and auto-escaping, which means that views does not longer have to care about it.

A test for both would be more convincing: put something in a plain database field and/or an entity base field that needs to be escaped away or XSS filtered and verify that it is using the generic 'string' handler for Views or the 'field' handler for entities

Views escapes its own output anyway by default, this is done in the base plugin class, so I don't see a need to test functionality that has existed for a long time again. This will use check_plain by default. This has been around in views for...years. But we may not even need that in the long run.

So that is a change from just xss filtering before. Is that a change we can do? If not, we will need a mechanism so views data can declare the filtering it wants to use on the output.

New patch to fix the indentation.

And yes, for reasons Daniel already explained we need to touch the aggregator Xss plugin, it's a simple change, and breaks a dependency we really don't need.

Views escapes its own output anyway by default, this is done in the base plugin class, so I don't see a need to test functionality that has existed for a long time again. This will use check_plain by default. This has been around in views for...years.

Right, the XSS handle was always just a shortcut for developers for the underlying sanitizeValue method ... which is a feature which existed before autoescaping.

Yes, which after all of this, we could look at actually just removing altogether maybe...

Committed 0884e7b and pushed to 8.0.x. Thanks!