#Distributions and Recipes

Discussed #8 with @phenaproxima we agreed that in this situation the event is offering benefits - the event object collects skips and validates them. This type of collecting and validating with an object has not been done with hooks yet and there is no need for this to be first.

Also discussed with @longwave ahile back and we agreed to backport this to 11.1.x because while this is not a bug in core it helps fix a bug possible when you have trash installed - which Drupal CMS does.

Committed and pushed 51ae03891c1 to 11.x and c813f52a5be to 11.1.x. Thanks!

I don't think there's any real harm in backporting it, but also not much value (yet) beyond keeping it consistent, since RecipeInputFormTrait only appeared in 11.1.

Committed and pushed ac347da742f to 11.x and 379ebd46fcc to 11.1.x. Thanks!

We could backport this 10.4.x and 10.5.x if we choose.

This makes a lot of sense, some real fun nuance in there with

-  private ?array $values = NULL;
+  private array $values = [];

:D

Project Browser can work around this problem (by prying open the static cache with reflection and clearing it), so this is not a stable blocker for Drupal CMS.

But it is a legitimate bug that needs to be fixed. :)

Tests are failing as expected: https://git.drupalcode.org/issue/drupal-3495305/-/jobs/3776754#L54

This is ready for review and has failing test coverage.

phenaproxima → changed the visibility of the branch 3495305-test-only to hidden.

Looks good to me, thanks @phenaproxima! Left a comment on the MR, feel free to close it if you disagree :)

And, done.

Hmmm...yeah, okay @amateescu, you've convinced me that we should support filing a reason why the skip happened (the reason should be optional). Trash's use case makes perfect sense.

Trash could use that to say that an entity was skipped because one with the same UUID is in the trash bin.

I would advocate to do that in a follow-up.

Marking as RTBC. Love to see some more improvement in the default content system!

Went ahead and implemented the skip mechanism.

Automatically closed - issue fixed for 2 weeks with no activity.

Tagging as a target so it's on the radar somewhere, it's intended to be used for nice-to-haves.

This is not a Drupal CMS stable blocker. It would be very nice to have it, and hopefully it can land in a patch release of 11.1.x as a change in an experimental subsystem, but it does not block a stable release of Drupal CMS. Getting this would, however, allow us to avoid a nasty bug that is relatively edge-casey, so keeping it as a release target in case this lands in a core patch release before Drupal CMS's general launch.

I discussed this with @tim.plunkett and @pameeela and we decided it is not a Drupal CMS stable blocker. It's a nasty bug, but likely an edge case. And besides, the fix depends on an upstream change in core that is not itself a Drupal CMS stable blocker. So by extension, this isn't either. I'm downgrading it to a release target, as it would be nice to get it fixed if core can get the requisite change into 11.1.2 (and hopefully that gets tagged before we launch 1.0.0).

Discussed with @penyaskito and we agreed that this is nice to have, and would accelerate Drupal CMS's dashboard work track, but is not a stable blocker.