Broken/missing handler for Moderation state field

Fixing this is a follow up to #2845151: ContentModerationStateFormatter pretends it's for the moderated entity, but it is for the content moderation state entity.

This gets exposed in \Drupal\content_moderation\ViewsData::getViewsData. The views data array has an issue, no field plugin is set:

'field' => ['default_formatter' => 'content_moderation_state'],

\Drupal\views\Plugin\views\field\EntityField doesn't work because the field is computed. We have two ways of fixing this:

1. Provide a custom views field plugin for this field.
2. Provide good generic computed field support.

I have made a start on the latter in #2852067: Add support for rendering computed fields to the "field" views field handler.

If #2852067: Add support for rendering computed fields to the "field" views field handler gets in, it will be trivial to add the computed handler to the computed field to show the pretty name.

Are there any news on that? I have the same problem WITH the relationship to Moderation state. Drupal 8.3.3

As handkerchief says, same issue here too - I have the relationship, but still a broken handler (Drupal 8.3.5).

I wonder if this will be fixed by #2862041: Provide useful Views filters for Content Moderation State fields.

@timmillwood, sadly.. nope :)

No, but a combination of #2852067: Add support for rendering computed fields to the "field" views field handler and #2902187: Provide a way for users to moderate content will.

Here is the fix for displaying the field, in case anyone needs it for 8.4.x. It might make sense to get this in ahead of #2902187: Provide a way for users to moderate content, because since this is now supported by the default handler, this could be classed as a bugfix, whereas that is a feature that'll only land in 8.5.

I have this patch applied on an upgraded 8.4 site. I'd still love to get this backported as a bugfix.

I tried the patch on Drupal 8.4.2, but I still get the error "missing handler". How could I port this back, do you have some advice? Thank you :).

This patch works when adding the "moderation state" field that is attached to the moderated entity, not the state field on the content_moderation_state relationship. Make sure caches are cleared after applying the patch.

The content moderation state field is still completely broken in 8.4, as soon as you add the field it says the field is broken/missing handler. This really should be backported to 8.4.x.

The patch looks reasonable but this should have some automated test coverage.

Works for me too. Thanks.

This may be useful to others but here's a patch that applies against 8.4.x after applying the related #2862041: Provide useful Views filters for Content Moderation State fields patch.

Test looks good to me!

unrelated test failures... retesting #23

+++ b/core/modules/content_moderation/src/ViewsData.php
@@ -78,7 +78,7 @@ public function getViewsData() {
+        'field' => ['id' => 'field', 'default_formatter' => 'content_moderation_state', 'field_name' => 'moderation_state'],

@@ -97,7 +97,7 @@ public function getViewsData() {
+        'field' => ['id' => 'field', 'default_formatter' => 'content_moderation_state', 'field_name' => 'moderation_state'],

nit: these should be one per line for phpcs sake

Interdiff:

diff --git a/core/modules/content_moderation/src/ViewsData.php b/core/modules/content_moderation/src/ViewsData.php
index e6c9a52f67..9ade858c38 100644
--- a/core/modules/content_moderation/src/ViewsData.php
+++ b/core/modules/content_moderation/src/ViewsData.php
@@ -78,7 +78,11 @@ public function getViewsData() {
             ],
           ],
         ],
-        'field' => ['id' => 'field', 'default_formatter' => 'content_moderation_state', 'field_name' => 'moderation_state'],
+        'field' => [
+          'id' => 'field',
+          'default_formatter' => 'content_moderation_state',
+          'field_name' => 'moderation_state',
+        ],
       ];
 
       $revision_table = $entity_type->getRevisionDataTable() ?: $entity_type->getRevisionTable();
@@ -97,7 +101,11 @@ public function getViewsData() {
             ],
           ],
         ],
-        'field' => ['id' => 'field', 'default_formatter' => 'content_moderation_state', 'field_name' => 'moderation_state'],
+        'field' => [
+          'id' => 'field',
+          'default_formatter' => 'content_moderation_state',
+          'field_name' => 'moderation_state',
+        ],
       ];
     }

diff --git a/core/modules/content_moderation/tests/src/Kernel/ViewsDataIntegrationTest.php b/core/modules/content_moderation/tests/src/Kernel/ViewsDataIntegrationTest.php
index dcadd03..a1b396f 100644
--- a/core/modules/content_moderation/tests/src/Kernel/ViewsDataIntegrationTest.php
+++ b/core/modules/content_moderation/tests/src/Kernel/ViewsDataIntegrationTest.php
@@ -147,5 +147,4 @@ public function testContentModerationStateField() {
     $this->assertIdenticalResultset($view, $expected_result, ['title' => 'title', 'moderation_state' => 'moderation_state']);
   }
 
-
 }

fixed on commit

I think there is a small bug in this code.

The moderation state that we display should not be the latest default state but rather the latest state. For example, in the default editorial workflow with draft, published, and archived states, published and archived are default states while draft is not.

Lets say an editor creates a new article and saves it as draft. The moderation state field will say draft.

Next, they publish the article. The moderation state field will say published.

Later, if they create a new draft and save it the moderation state field will still say published. I think this is incorrect behavior. I think if a draft exists that is newer than the latest published state, the field should say draft.

Thoughts? https://youtu.be/9wPQRDo_fHY

The behavior in #34 is by design. If you want to display information from the latest revision of an entity, you need to add a relationship to it (not sure if that exists in core yet) or create a view of revisions and use the "Is latest revision" filter to only show one latest revision per entity.

I've rerolled this patch apply for latest 8.4.x.
It also include this issue https://www.drupal.org/node/2862041

Hey @tvhung, any reason this needs to be rerolled for 8.4? The 8.4 branch is current unsupported, so sites should upgrade to 8.5 where possible.

@sam152 I think you answered your own question when you used the words "should" and "where possible"

@chOP, that doesn't explain why. If the blocker to upgrading to 8.5 is related to content_moderation in some way (which could kinda be correlated by the need to reroll patches for a beta version of the module), that's helpful to know about because it could affect others.

Reverting to committed version