- Issue created by @pameeela
- πΊπΈUnited States thejimbirch Cape Cod, Massachusetts
Can we not actually ship the site template recipes with Drupal CMS, and instead require them on application?
Leaving recipes in the code base of an existing site leads to dependency locking and can block site owners from updating.
We have already seen this on Drupal CMS 1.0, where users will have to update the SEO Tools recipe in order to update the field_group module from v3 to v4. Recipes were designed to be ephemeral and not stick with the site they have been applied to for these dpendency issues.
Now that recipes are unpacked in Drupal CMS 2.0, and project browser can be used to list projects from APIs, we should be able to fulfill the requirement to offer three site templates to Drupal CMS, but not actually "ship" them in the code base.
- πΊπΈUnited States phenaproxima Massachusetts
Now that recipes are unpacked in Drupal CMS 2.0
This is also the case in 1.2.0. Just wanted to be clear about that, in case anyone sees this issue and thinks they have to wait until autumn for recipe unpacking.
- π¦πΊAustralia pameeela
Can we not actually ship the site template recipes with Drupal CMS, and instead require them on application?
Yes, but from the user's perspective it makes no difference, the options come with it. So 'ship with' is not implying any implementation specifics, just a way of describing the experience.
- πΊπΈUnited States thejimbirch Cape Cod, Massachusetts
I understand, but developers can take product owners words literally, so thank you for the clarification.
- πΊπΈUnited States hestenet Portland, OR πΊπΈ
Merging back in a discussion from [#3528683#comment-16175309] which I think better belongs here...
As is clearly stated in the issue summary by @pameela, there are still a lot of unknowns here, but I think we can specify the ideal case:
We know we want:
- to allow users to install, maintain, and update DrupalCMS with as minimal interaction with command line as possible
- to move to a model where DrupalCMS is foundational, and site templates become the building blocks applied to kick-start specific use cases
- to offer site templates that 'ship with'(whatever that will technically mean, not fully defined) with DrupalCMS
- to have site templates be easily discoverable in the long term
We also want to avoid:
- Leaving behind components in the codebase that are unused, but are still included as dependencies in composer.json because they can prevent site updates
There's some positive progress because recipe unpacking is done automatically as of 1.2.0, however, if unneeded dependencies are left behind they may still need to be
composer remove such-and-such
to clear the way for an update.So, as @pameela has said, we still have the power to define what 'shipping with' site templates means on a technical level, in order to meet all these constraints, and still be transparent to the user
I think right now the issue that solves the unused-but-blocking dependencies but allows us to make a transparent installation process for the user is:
- β¨ Create a Contrib Recipes source plugin Active
Are there other related issues we should gather here and/or create?