Modify EntityAggregatorSensor to only aggregate content entities.

Actually, I think we should do exactly that. Hide non-content entities, possibly rename the sensor ContentEntityAggregatorSensor.

1. Validating this will be very hard. There are per-bundle fields and so on. Instead, make it not fatal if a field doesn't exist. as mentioned before, use hasField() on the entity before accessing it.

2. That's a separate bug, the exists callback is supposed to prevent that.

1. +++ b/config/install/monitoring.sensor_config.user_active.yml
   @@ -2,7 +2,7 @@ id: user_active
    label: 'Active users'
    description: ''
    category: 'User activity'
   -plugin_id: entity_aggregator
   +plugin_id: content_entity_aggregator
    value_label: 'Users'
    value_type: 'number'
    status: FALSE
   

   Not sure about this, might make a bit more sense, but it will also break existing installations completely.

   I'd keep the current name for now.

2. +++ b/src/Plugin/monitoring/SensorPlugin/ContentEntityAggregatorSensorPlugin.php
   @@ -291,12 +297,13 @@ class EntityAggregatorSensorPlugin extends DatabaseAggregatorSensorPluginBase im
          '#maxlength' => 255,
   -      '#options' => $this->entityManager->getEntityTypeLabels(),
   +      '#options' => isset($options['Content']) ? $options['Content'] : [],
          '#title' => t('Entity Type'),
   

   That problem again ;)

   Doesn't quite work like that, Content is a translatable string, so you would have to at least put t() around it. And I prefer to loop over entity types and check the entity class against the interface mentioned above. Contrib might add additional groups.

Nice interdiff (0 bytes) ;-P

+++ b/src/Plugin/monitoring/SensorPlugin/ContentEntityAggregatorSensorPlugin.php
@@ -242,9 +244,14 @@ class EntityAggregatorSensorPlugin extends DatabaseAggregatorSensorPluginBase im
+              $row[] = t('invalid field');

+++ b/src/Plugin/monitoring/SensorPlugin/ContentEntityAggregatorSensorPlugin.php
@@ -255,7 +262,7 @@ class EntityAggregatorSensorPlugin extends DatabaseAggregatorSensorPluginBase im
+      $header = $this->sensorConfig->getSetting('verbose_fields', ['ID, Label']);

+++ b/src/Plugin/monitoring/SensorPlugin/ContentEntityAggregatorSensorPlugin.php
@@ -291,12 +298,20 @@ class EntityAggregatorSensorPlugin extends DatabaseAggregatorSensorPluginBase im
+    $entity_types = $this->entityManager->getEntityTypeLabels();
...
+    foreach (array_keys($entity_types) as $delta => $type) {
...
+        $options[array_keys($entity_types)[$delta]] = array_values($entity_types)[$delta];

+++ b/src/Plugin/monitoring/SensorPlugin/ContentEntityAggregatorSensorPlugin.php
@@ -416,8 +431,8 @@ class EntityAggregatorSensorPlugin extends DatabaseAggregatorSensorPluginBase im
+        '%fields' => implode(', ', array_keys($this->entityManager->getBaseFieldDefinitions($this->getEntityTypeId())))
         ]
       ),

And finally, dreaming of nice test coverage...

The "invalid field" output should be completely dropped like the field is empty. Otherwise it is too much visual noise.

Didn't get that last change. The file entity thing is a core bug, I've opened #2539622: File uri field type has default formatter uri_link, throws exception when trying to render.

I've added a try/catch around it and then I'm just displaying that error. We need to do that more often to avoid completely broken pages.

And committed!