Add validation constraints to core.entity_form_mode.*.*

Applied some nitpicky typehint return voids

Applied the MR to a 11.x install using standard profile
Believe the only entity_form_mode is for core.entity_form_mode.user.register
Ran updb and hook ran without issue

Manually downloaded config_inspector to 11.x setup and confirmed seeing fully validatable now

One issue with the presave hook on the MR - missing a deprecation notice.

Left some comments on MR.

Deprecation appears to be correct to me.

One small comment on the deprecation message. Hard to fit this sort of thing into the standard format.

Message seems good

Left one question on the MR, great work here - bit more involved with the update hook!

This issue is ready for re-review. I have added the return FALSE. Thanks

Looks okay but I have a couple of questions here.

Only one tiny thing and then I think this looks good.

Applied MR on a standard install for 11.x with config inspector and getting all green checks.

Looking at MR 8135 and from what I can tell all feedback has been addressed.

If I go to admin/structure/display-modes/form/ and edit the user registration form and save the form mode with no description then the system_entity_form_mode_presave() will trigger a deprecation notice.

We need to add something to the form to convert empty strings to NULLs... normally we'd say use #config_target but we've not worked out how to using #config_target like stuff with config entities yet.

Tested the scenario in #21 has been addressed with https://git.drupalcode.org/project/drupal/-/merge_requests/8135/diffs?co...

I'm not sure that a NULL description is any better then an empty string. Do we think that this part of the change is actually worth it?

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. 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.

I'm not sure that a NULL description is any better then an empty string. Do we think that this part of the change is actually worth it?

I don't feel strongly one way or the other, so I'm assigning this to Wim for input. I suspect he has a clearer reason why NULL would be useful here.

Going through the config issues a bit to see where things are hanging.

I read through all this, and have not seen any discussion around the NULL change. I understand the text in the CR ("The reason is because an empty string makes no sense for this field. "" is never a useful description of a form mode."). But I dont really see why this is as much better as it is a change.

If i try to argue why it should be null: Now i want no desription is equal to en empty description. This unfortunately meant he field is not really optional, when you wouldn't post an description you technically tend a NULL, which cannot be stored right now. But if we allow null, we would be able to save without the field, since null is fine.

This could have reasons in jsonapi, maybe we can then post without the field and make it null, instead of requiring an empty string?

This is as far as i get.

Removing wim from assignment, that will probably not make this go faster.

My conclusion in #27 is that null is a good idea. I rebased and if tests don't fail I think this can move forward as is. Since my additions were minimal, setting RTBC.

Seems fixtures might need work. Not sure how those work.

Found the tiniest of nitpicks, this is just a version number change in the deprecation, so leaving at rtbc.

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. 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.

Rebaed.

We need to move the hook implementation to the correct new OOP place... \Drupal\system\Hook\SystemHooks

Thanks, you are right. By now we have the OOP hooks. I think this issue is present in the other validation issues also. I'll do a round.

I think this change is so minimal i can RTBC again. I ran the upgrade test after moving the hook code to SystemHooks.php and it upgraded fine.

Committed 4f3432b and pushed to 11.x. Thanks!

CR was out of date regarding versions, does it need publishing also? Probably?