Add validation constraints to core.entity_view_mode.*.*

Nice progress here! 😄 Still needs some work, but for each of the things that still need to be addressed, there's prior art/patterns to look at 😊

What I think is remaining is the tests updates. I see there's a few failing due to configuration tests as it's noting that the core.entity_view_mode.* config files have been changed and updated. This is to be expected given the hook_post_update_NAME() being included here.

Drupal\FunctionalTests\Installer\InstallerExistingConfigMultilingualTest::testConfigSync
Failed asserting that two arrays are equal.
--- Expected
+++ Actual
@@ @@
 Array (
     'create' => []
     'update' => Array (
-        0 => 'system.mail'
+        0 => 'core.entity_view_mode.node.teaser'
+        1 => 'core.entity_view_mode.node.se...result'
+        2 => 'core.entity_view_mode.node.se..._index'
+        3 => 'core.entity_view_mode.node.rss'
+        4 => 'core.entity_view_mode.node.full'
+        5 => 'system.mail'
+        6 => 'core.entity_view_mode.user.full'
+        7 => 'core.entity_view_mode.user.compact'
     )

Is the right thing to do here update the tests so they expect all those view mode configuration changes? Testing is an area I'd like to be able to contribute to more so any information folks can provide is much appreciated.

Replied to the comment and applied 2 nitpicky things

On a 11.x setup with standard install there are several view modes across entity types
Applied the MR locally
Update hook ran without issue

Manually downloaded config inspector and am seeing fully validated entity_view_modes

One note on the MR - missing a deprecation message. 🐛 Add proper deprecation notices in config entity presave bc layers Active has more details.

The Needs Review Queue Bot → tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Thanks for your continued contributions in the config validation space, @carsoncho! 🙏😊

A few nits, and one question about a comment that seems wrong.

The MR itself looks great! 👍

Updating description to 'description' => NULL is giving depreciation error. Other feedback addressed.

Feedback addressed.

Updating description to 'description' => NULL is giving depreciation error.

The deprecation error you're seeing is literally the one this MR is adding.

Why does that deprecation exist here? node_node_type_presave() doesn't do that (introduced in 📌 Allow vocabularies to be validated via the API, not just during form submissions RTBC .) Ah … because @catch asked for that.

Well, now we've got ourselves a chicken-egg situation. 😅

The only way I see out of this is to not rely on the presave hook to perform the update, but instead to duplicate that logic into the update hook.

Re #25, Does it mean removing system_entity_view_mode_presave() from system.module and doing $view_mode->set('description', NULL)->save(); in system_post_update_convert_empty_string_entity_view_modes_to_null of system.post_update.php. Also where should we use @trigger_error in this case or it can be avoided?

When I did as above it gives Schema errors for core.entity_view_mode.node.teaser with the following errors: 0 [description] This value should not be blank.