- Issue created by @mandclu
- π¨π¦Canada mandclu
Here's a small MR to add suggestions for the event add-ons that already exist in the contrib space, instead of reproducing them as small, additional recipes within Drupal CMS.
- πΊπΈUnited States phenaproxima Massachusetts
One small nit from me, no objection otherwise.
However, the bigger question here lands squarely in @pameeela's bailiwick. If we do decide to ship these add-ons with Drupal CMS, then we'll want to add test coverage to prove that they all apply cleanly on top of both the Events recipe and the Starter recipe.
- π¨π¦Canada mandclu
IMHO if the recipes won't be applied as part of the initial site install, it makes more sense to not load dependencies until the recipes are going to be applied. Happy to defer to @pameeela on this, however.
- π¦πΊAustralia pameeela
Hmm. I'm not sure this is sufficient because we will be showing the event recipe in the onboarding, but are unlikely to include the idea of 'optional additions' at that point, because we want to keep the decisions to a minimum and get folks into their sites. So I definitely think there is value in having them presented in the recipes UI. (This UI is currently being scoped out and we do hope to have it for v1!)
If someone doesn't apply the event recipe in the onboarding, then we could use the suggestions to show optional add-ons during the later application.
- πΊπΈUnited States phenaproxima Massachusetts
Okay, there are two options here:
- Keep the three recipes in contrib, and bring them into the project template as dependencies.
- Merge them wholesale into Drupal CMS, and deprecate the contrib projects.
Either way, we can show them in Project Browser. I like door #2. @tim.plunkett is agnostic. It sounds like Pam is more on the door #2 side.
I think @mandclu must choose.
- πΊπΈUnited States phenaproxima Massachusetts
Okay, great. So the next steps here:
- Add these recipes as dependencies to
project_template/composer.json
- Add a little test coverage to the starter recipe which confirms that they all apply on top of it
Now that the decision has been made, this can land during beta.
- Add these recipes as dependencies to
- πΊπΈUnited States phenaproxima Massachusetts
Welp, this is blocked.
The problem is that those three add-ons rely on the contributed Events recipe, which conflicts with the Drupal CMS Events recipe (although only slightly).
I proposed one possible solution to @mandclu, which is to use
strict: false
(or really, selective strictness) in the contributed Events recipe. That would allow that recipe to apply harmlessly to a fully installed Drupal CMS site; indeed, I tested that locally and it got me past the conflict.The problem is that
strict
is only available in Drupal 10.4+ and 11.1+, so it would necessitate some release management tomfoolery on the contrib side.So this is blocked until a new version of the contrib Events recipe, which can be applied to Drupal CMS, exists.
- πΊπΈUnited States phenaproxima Massachusetts
@mandclu fixed a couple of bugs in the upstream Events recipe, so this is now unblocked! Let's see if we can get it merged today.
- πΊπΈUnited States phenaproxima Massachusetts
The Event content type has now significantly deviated from the event add-ons in contrib, and I am therefore unsure that we're compatible with them anymore, sadly. We'll have to look into this after 1.0; this won't happen for our initial release.
- πΊπΈUnited States phenaproxima Massachusetts
If we're able to do this at all, it will be in the next minor version (v1.1.0) of Drupal CMS.
- Status changed to Needs work
3 months ago 1:37pm 16 January 2025 - πΊπΈUnited States phenaproxima Massachusetts
I still think there is value in the add-ons, but due to the diverged content models, we should probably just fully port the add-on functionality into the main Events recipe. (It would be better than adding even more recipes to Drupal CMS -- the number of components is already nearly unsustainable from a release management perspective.)