Make pre-save entity validation more commonplace (e.g., the default)

Related: Drupal's migration system does not validate content entities upon migrating them, unless you manually opt in to that. (See \Drupal\migrate\Plugin\migrate\destination\EntityContentBase).

I personally am strongly in favor of this, I've run into this the first time while working on Drupal's REST API in early 2016.

But that's also when I learned there are Reasons it works this way and that it's impossible to change. At least at the time. We've learned a lot about evolving a codebase without breaking BC. Maybe this is the kind of change we'd give people 2 major releases worth of time to adopt instead of 1.

This immediately made me think of this: #3118590: Media library allows adding videos from providers other than Youtube/Vimeo using Media embed →

Leveraging entity validation would likely be the best solution to that one.

Maybe this is the kind of change we'd give people 2 major releases worth of time to adopt instead of 1.

I think this is the kind of thing we could have "on" by default on new installs and opt-in for existing sites? That addresses much of the BC concern?

At its core that issue results from relying on form validation instead of entity validation.

BINGO. This is the issue. Too much logic in the form API layer instead of in the core entity APIs.

I think this is the kind of thing we could have "on" by default on new installs and opt-in for existing sites? That addresses much of the BC concern?

I'm not sure that would work - the bc concern is more that modules/migrations will be out there relying on the existing behaviour, and then when that module is installed on a new site, it will suddenly break. It would help custom code since that's generally maintained on existing sites, but not contrib/distributions.

I haven't looked into what it would take, but I'm wondering about something like [#3201242] - i.e. all entity saves are required to opt in or out of validation, and then in a major release throw an exception if it's not specified. Then there's no default to change at all. The issue with that is the amount of actual change required is higher than just changing the default.

Maybe a hybrid would be to trigger_error if we're setting the default, with a notice that the default will change. Then modules can either ignore that deprecation message if they don't mind, or explicitly opt in or out to get rid of it. But then in the major release we'd remove the deprecation message and change the default, no exception throwing.

That's an interesting thought; the logic is kinda-sorta in line with what I developed in my trait which I attach to entity classes I want to force validation on: https://tech.kinksters.dating/posts/2022-08-18-trait-always-validate-ent...