Default value not correctly set in the ModerationStateWidget.

yeh, that is a bit weird isn't it?

The issue with setting it to the current state is that the current state might not always be a valid transition, so we'd need check if the current state is in $transition_labels before setting it as the default.

Also this needs tests for the default value and the case stated above.

I think the only state that ships with core that can't be maintained is "Archived", when editing an archived entity it has to move then either to be a new draft or published.

New patch looks like a nice solution, but still needs tests 😉.

I can confirm patch #4 working well.

As stated in #5, this needs tests!

Sorry for this misunderstanding, i'm not very good with tests but i think that i got it.
Please review.

Thanks for reporting this! I'm migrating from workbench moderation and saw this strange behavior as well. I think the approach taken makes perfect sense - default to the current transition if available, otherwise just use the first.

As for the tests, I think a bit more work can be done for the tests for better coverage - basically to test that the current state is selected when it's available in the list, and that the first item is selected otherwise.

Looks good, thanks for adding the test @Anas_maw!

+++ b/core/modules/content_moderation/tests/src/Functional/ModerationFormTest.php
@@ -107,6 +107,10 @@ public function testModerationForm() {
+    // Check widget default value.
+    $this->drupalGet($edit_path);
+    $this->assertFieldByName('moderation_state[0][state]', 'published', 'Moderation state default value is not set.');

Tiny nit: in the assertion messages we should write the expected behavior, "the default moderation state value was set correctly" or "expected the moderation state default value to be set correctly" and the test runner would highlight the correctness of the statement.

If the assertion was passing, it would be confusing the see a message saying "moderation state default value is not set". You would assume this was the intended behavior when it is in fact the opposite!

@Sam152 You are right, here is an updated patch with the suggested message.

Looks great, thanks!

Looks good for me.

Temporary testbot hiccup.

+++ b/core/modules/content_moderation/tests/src/Functional/ModerationFormTest.php
@@ -107,6 +107,10 @@ public function testModerationForm() {
+    $this->assertFieldByName('moderation_state[0][state]', 'published', 'Expected the moderation state default value to be set correctly.');

Shouldn't the message just be "The moderation default value is set correctly."?

Updated with the suggested message.

Credited @timmillwood, @Sam152 and @catch as they made comments that impacted the patch.

Committed and pushed 19d0533ffa to 8.6.x and 0b35eb08fe to 8.5.x. Thanks!

Hi! Somehow I've *gained* this problem since updating from Drupal 8.5.3 to 8.5.6 -- I'm sure it's me, seeing as no one's commented on this issue since April, and the patch was included in 8.5.4 which has been out for over two months -- but I'm really not sure how to try to figure out why it's happening to me now. Did y'all go thru any regressions while creating/testing/applying these changes...?

>> What's happening to me (just to make sure it is indeed the same issue):
-- I edit a content type (admin/structure/types/manage/mytype)
-- Publishing options > Default options > "Published" is unchecked
-- I enable "Published"
-- I save the form
-- I edit that same ctype again (admin/structure/types/manage/mytype)
-- Publishing options > Default options > "Published" is unchecked

@alisonjo2786
This issue was for the content, not for the content type settings form.
I went through the steps you provided, and yes i found the same problem.
I this you should open a separate ticket for this issue.

Oh oh okay, thank you I absolutely will!

Done -- thanks again, @Anas_maw!
#2990926: Node type: Default publishing option won't save as Published