Provide an area handler that renders an entity

+++ b/core/modules/system/lib/Drupal/system/Plugin/views/area/Entity.phpundefined
@@ -0,0 +1,117 @@
+    $form['view_mode'] = array(
+      '#type' => 'select',
+      '#options' => $options,
+      '#title' => t('View mode'),
+      '#default_value' => $this->options['view_mode'],
+    );

I think view mode should be first, but that's just me :)

+++ b/core/modules/system/lib/Drupal/system/Plugin/views/area/Entity.phpundefined
@@ -0,0 +1,117 @@
+    // Add tokenization form elements.
+    $this->tokenForm($form, $form_state);

Do we want all the token form available here.

+++ b/core/modules/system/system.views.incundefined
@@ -0,0 +1,26 @@
+      'title' => $label,

I think we should prefix this label with 'Rendered entity: ...' or something? People could easily get confused about the fact that every entity has on of these OR .. (Which I think is preferable) is to just have one generic rendered entity handler. So have an additional entity select field.

+++ b/core/modules/system/system.views.incundefined
@@ -0,0 +1,26 @@
+      'help' => t('Shows an @label in the area.', array('@label' => $label)),

Either way we could change this to something like, 'Render an entity....blah'

+++ b/core/modules/system/system.views.incundefined
@@ -0,0 +1,29 @@
+ * Provide views data and handlers for node.module.

This says node.module, in system.views.inc

Also, catch seemed rather reluctant to add views integration in system module

Yeah, this might have to move into views instead.

Getting this issue going again (I know it's only been 5 days :)).

The previous patch was not filtering out the view entity type, as it was looking for 'views' and not 'view'. So I added some more test coverage for the data side of things.

I also changed the check to just check for all config entities, as we don't really want any of them. See interdiff.

How about looking for things that provide a render controller class? Blocks will have that. And views can too #1857422: Add a ViewBuilder for Views, those can be used in an area handler currently.

Yeah, that sounds sane. Do defaults get assigned for this?

Oh damn, it has a default of EntityRenderController, so EVERYTHING will have one. I'll open an issue to remove that default, all entity types shouldn't be renderable.

See #1882240: Remove default assignment of render_controller_class in EntityManager

Yeah, I thought we might have a problem with this. That issue makes sense.

Looking good overall, just a couple of things:

+++ b/core/modules/views/lib/Drupal/views/Plugin/views/area/Entity.phpundefined
@@ -0,0 +1,118 @@
+    $form['entity_id'] = array(
+      '#title' => t('ID'),
+      '#type' => 'textfield',
+      '#default_value' => $this->options['entity_id'],
+    );

I guess just having the entity ID is what we have to do, as an entity doesn't have to have a path, but maybe people expect a path? Just food for thought

+++ b/core/modules/views/lib/Drupal/views/Plugin/views/area/Entity.phpundefined
@@ -0,0 +1,118 @@
+    if (!empty($this->entityInfo['view_modes'])) {
+      foreach ($this->entityInfo['view_modes'] as $mode => $settings) {
+        $options[$mode] = $settings['label'];
+      }

This should use entity_get_view_modes now.

+++ b/core/modules/views/lib/Drupal/views/Plugin/views/area/Entity.phpundefined
@@ -0,0 +1,118 @@
+      $entity_id = $this->globalTokenReplace($this->options['entity_id']);

Nice, we get ALL THE TOKENS.

+++ b/core/modules/views/lib/Drupal/views/Tests/Handler/AreaEntityTest.phpundefined
@@ -0,0 +1,91 @@
+    $entity_info = $this->container->get('plugin.manager.entity')->getDefinitions();

ughhh. I want entity_get_info back.... :)

+++ b/core/modules/views/lib/Drupal/views/Tests/Handler/AreaEntityTest.phpundefined
@@ -0,0 +1,91 @@
+    $entity_test = $this->container->get('plugin.manager.entity')->getStorageController('entity_test_render')->create(array('bundle' => 'entity_test_render', 'name' => $random_label));

Would having a variable for $data of something make that verboseness better?

+++ b/core/modules/views/lib/Drupal/views/Tests/Handler/AreaEntityTest.phpundefined
@@ -0,0 +1,91 @@
+    $this->assertEqual(trim((string) $result[0]), $random_label, 'The rendered entity appears in the header of the view.');

Is there any way we can assert something to do with the view mode too? Might be tricky with entity_test.

+++ b/core/modules/views/lib/Drupal/views/Plugin/views/area/Entity.phpundefined
@@ -0,0 +1,118 @@
+ *   id = "entity"

We should add views as the module here, as we are probably removing the default in ViewPluginManager. This could wait but I guess we might as well add it while the patch is being worked on? If not, we can just add it when we do that change.

If it's a smallish change (adding the view mode), which I think it should be? Then I say go for it in here, then it's out of the way and tested. Once it is rendered, the assertion is pretty quick to add I guess.

Good idea using the entity reference autocomplete! That will make a nice follow up issue.

I wont change the status yet in case you want to roll a new patch with the view mode? Otherwise, test away.

Awesome, This is great now. Sorry if those tests took a while :/ They are good though! I think that makes much better coverage.

+++ b/core/modules/views/lib/Drupal/views/Plugin/views/area/Entity.phpundefined
@@ -0,0 +1,105 @@
+  protected function buildViewModeOptions() {

This is a good idea, for easy overriding if needed.

Since this is an entity system integration (and required to convert the taxonomy term view) I think this is more of a task.

I don't really get allowing an explicit ID here, for taxonomy terms it's going to need to take the term from arguments and the test is hard-coding this to a test entity with ID = 1?

For taxonomy/term, while I don't really like them, I'd normally except the taxonomy term at the top to be an attachment.

I'd still like to know what we get from this compared to using an attachment display (except for not having to instantiate two displays). Or wait if one display is listing nodes and the other taxonomy terms is that why?

+++ b/core/modules/views/lib/Drupal/views/Plugin/views/area/Entity.php
@@ -0,0 +1,111 @@
+    $options = entity_get_view_modes($this->entityType);
+
+    return $options;

Here should be some processing for options before returned and used in view mode select.

+++ b/core/modules/views/lib/Drupal/views/Plugin/views/area/Entity.php
@@ -0,0 +1,111 @@
+        $build = entity_view($entity, $this->options['view_mode']);
+        // @todo Support to just return a render array.
+        return drupal_render($build);

Do we have an issue for this @todo somewhere?

Sorry, see EntityRow::buildViewModeOptions() or add rendered entity to header and select view mode.

This is looking great now!

The testbot could really be nicer and give some better error messages. :-)

On the other hand it would help if I run the tests myself. Humans 1 - 1 Machines.

Thanks @dawehner for pointing this out.

this is blocking #1857256: Convert the taxonomy listing and feed at /taxonomy/term/%term to Views, also changes is legit. back to rtbc, it is going to take the bot a while to catch up but it ll let us know if it disagrees

Reviews are mixed on that point. I know Bojhan's not a fan, I'm equally not a fan of hiding things under the covers, especially when a word actually means what it is (unlike "node").

However, since strings are something we can change anytime before RC1, I think it's ok to let this go in and have a follow-up discussion about that.

Committed and pushed to 8.x. Thanks!

+++ b/core/modules/views/lib/Drupal/views/Tests/Handler/AreaEntityTest.php

+  public function testEntityArea() {
...
+    $result = $this->xpath('//div[@class = "view-header"]');
+    $this->assertTrue(strpos(trim((string) $result[0]), $entities[0]->label()) !== FALSE, 'The rendered entity appears in the header of the view.');
+    $this->assertTrue(strpos(trim((string) $result[0]), 'full') !== FALSE, 'The rendered entity appeared in the right view mode.');
+
+    $result = $this->xpath('//div[@class = "view-footer"]');
+    $this->assertTrue(strpos(trim((string) $result[0]), $entities[1]->label()) !== FALSE, 'The rendered entity appears in the header of the view.');


+++ b/core/modules/views/tests/views_test_config/test_views/views.view.test_entity_area.yml

+      header:
...
+          entity_id: 1
...
+      footer:
...
+          entity_id: !1

A hidden gem in the footer area entity_id.

Should the tests have passed? Depends on whether entity_test entity IDs are integers, and whether 0 is a valid entity ID.

> php -r "var_dump((int) '!1');"
int(0)

Can we please, please, please open followups rather than resurrecting closed issues? Until we can make some changes to improve the issue queue UX, reopened, multi-commit, sprawling issues present a barrier to contribution. They create confusion when blaming for the commit log, muddy the issue scope, make the subsequent changes more difficult to review, and make it more difficult to assign self-contained cleanups or bug fixes to novices.

Filed #1957050: Bugged tests in the entity error handler?.