View output is not used for entityreference options

Please also consider those that participated in #2714089: Views Filter by an entity reference view not working as expected when assigning issue credit. Done, see #84.

Problem/Motivation

When an entity relation field displays options via a view the view fields are not used, instead it is the entity label. This is a regression from Drupal 7.x.

Proposed resolution

Update \Drupal\views\Plugin\EntityReferenceSelection\ViewsSelection::getReferenceableEntities() to return the Views result rather than just the entity label.

Remaining tasks

From feedback from @alexpott on #2174633-159: View output is not used for entityreference options

1. Calling strip_tags()

@alexpott: I think that rather than doing this we should use an inline template and the an inline list so that html in the labels is preserved. HTML in the labels can be super important - for example for translation and text direction when label's mix different languages.

@mikeker: I'm not dismissing the importance of I18N, but I think the basic use case should take precedence. Using strip_tags removes a lot of cruft and makes the error message more readable.... Agreed, but there was no way to see the auto-escaping bug without this fix. To me, they should be fixed at the same time. But if this is going to be a major sticking point, I'm happy to separate this out into a followup issue.

Current status: resolved (as per #164, but may need the patch changing to remove strip_tags() and open a new issue to discuss? Hopefully we can do this in a follow-up.)

2. Testing non-stripping of a tags

@alexpott: As far as I can see the whole a tag stripping thing is not tested.

Current status: addressed (as per #190)

3. Losing "safe-ness"

@alexpott wrote:

[renderPlain] is losing the "safe-ness" that is the result of the rendering. I think we might need a markup object object for this.

More clarification from him on #drupal-contribute (2018-01-12, paraphrased by @colan):

$this->renderer->renderPlain($row) returns an object that is considered safe by Twig and the render system. You are then using Xss::filter() to remove tags for example a from it; this returns a string, which is considered unsafe by the render system.

The shortcut is to use ViewsRenderPipelineMarkup to wrap the resulting string, but the better way is to avoid rendering here and instead of $return containing rendered strings, we let theming do everything for us (maybe something like ['#markup' => $this->renderer->renderPlain($row), '#allowed_tags' => $allowed_tags]).

Current status: unaddressed (but we have some direction now)

4. More tests

@alexpott wrote:

Given the nature of the change here I would expect more tests around double escaping

More clarification from him on #drupal-contribute (2018-01-12, paraphrased by @colan):

testAnchorTagStripping() [see #190] is a good start; nice one. But we also need a more functional test to ensure that the render system / twig doesn't go and double escape those <span>s and other tags. Use \Drupal\Tests\WebAssert::assertNoEscaped() as an example.

Current status: Fixed by #227

5. BC implications

@alexpott: I wonder about the BC implications of this change and whether or not we need a field that indicates whether to use the label or the view rendering. Because this might break existing implementations - right? If the view has been set up to not meet the expectations this change makes.

@mikeker: If a site builder setup a reference view for autocomplete and then realized that it wasn't working but left it there instead of reverting to the entity label option, then yes, they will be surprised when their view is being used in the autocomplete results. That seems expected to me -- we're fixing a bug and I don't believe we need to maintain BC for that.

@rootwork: I agree with @mikeker -- there's no reason you even would set up this field except to try to do what -- until this patch -- you cannot do. So it's hard for me to imagine that being a BC-breaking change.

Current status: resolved, pending OK by core maintainer

User interface changes

None.

API changes

In order continue injecting dependencies, \Drupal\views\Plugin\EntityReferenceSelection\ViewsSelection::__construct() will add a $renderer parameter. However, as per the BC changes documentation, this is allowed in minor version releases.

Data model changes

None.

Original report:

I'd like to prepend the content type to the referenceable item titles in the field autocomplete. An entity reference view rewrites the title field as [type]: [title], and is selected as the "view used to select the entities".

This does not appear to work - the view is used to assemble the list (tested by adding a view filter), but the autocomplete continues to display the item titles only.

This is a regression from entityreference 7.x-1.x