Make the recipe work for existing sites

working on it.

Hi @pfolk,
I've moved field.storage.node.layout_builder__layout.yml into optional folder so that it will be skipped if the file already defined in the site — avoiding the config conflict error.

Please check.

Thank,
Arun

Ah yes. Thanks Arun! That's definitely a step in the right direction. I am trying to make it so that we can apply the Recipe to Drupal CMS, but I've got to admit I have no idea how to get it to that point. I feel like if we can apply the Recipe to Drupal CMS then it will probably apply to most other sites.

So the install issue seems to be related to https://www.drupal.org/project/distributions_recipes/issues/3304895

By adding `strict: false` as the first entry under `config:` I can get the recipe to installed (The problem child was the system trying to install the navigation module and apply its config, which is not optional, and would require core change how that is handled or it be not strict in Plus Suite). I am now attempting to get the site to run in this state but I now get `The "" entity type does not exist. in Drupal\Core\Entity\EntityTypeManager->getDefinition()` which is of course my absolute favorite kind of entity to hunt down. I am investigating further as I am able.

My current suspicion is that some modules (possibly the + modules themselves) will need to be explicitly declared strict while the core modules can remain optional via the strict switch.

EDIT: Some initial snooping: I only get the error when I try to view my admin user. I will experiment further, but something about the user is not getting along with the system now that I installed plus_suite See followup comments for details, this was an issue with navigation+.

Tracked it down to Navigation+

Created an issue here: https://www.drupal.org/project/navigation_plus/issues/3518649

I have yet to test the plus_suite functionality of the system now that I have it installing, but progress!

Did some more testing this morning now that I had isolated the issue I was experiencing. I haven't tested the whole thing, but it is installable now and by creating a landing page through the updated navigation I was able to use the inline editing and layout builder features of the suite.

I am marking it as Needs Review as I am not an expert on the underlying modules and need those more familiar with them to verify everything is working.

It is also possible there are some dependent modules/config that cannot be optional. If so those should be explicitly labeled strict.

Yes that is working! Thank you very much!

Jim Birch was the one who told me to make it strict, but I guess I will leave that as a task for #futureMe to figure out.

Thanks again!

Check the issue description for steps to test. Thanks!

According to the issue I linked, Jim and many others are of the opinion that

Recipes are declarative and should not leave anything to be optional.

(see https://www.drupal.org/project/distributions_recipes/issues/3304895#comm...)

I am... less convinced that Recipes should leave things non-optional, especially when core modules have non-optional config and that means any two recipes that declare a dependency on those same core modules will not be able to be installed on the same site.

Hi folks,

I don't think the change was ever committed, but unlike modules, there are no subfolders in recipes config folder. Config files are either treated strict (Recipe will fail if it exists and is different), or lenient (Recipe will skip the config if it exists).

We recommend treating field.storage, entity.type configs strictly as they sculpt the database. But in real life, there are some configs that do more like layout_builder__layout and media field configs that are often changed on sites.

So right now, if that config exists on a site, your customizations are not applied. I don't use Layout Builder, but is this needed to make your recipe work?

persist_with_no_fields: node.type.landing_page.yml
  core.entity_view_display.node.landing_page.default.yml
  field.field.node.landing_page.layout_builder__layout.yml
  field.storage.node.layout_builder__layout.yml

I think this (plus_suite recipe) should be a module, plus_suite_ui or something like that. Many problems can be handled through .install and post_update for existing sites, thought. Clear README/documentation needed as well.
Anyway, ps_ prefix for these fields and node bundle landing_page can be considered as safe way to avoid field config duplication.
Looks like recipes are not designed to provide updates, but by my opinion this complex feature should. I can start a sandbox for this next week probably.

Yes I think you are right. I really want to add a drush commas or a wizard that helps people set up edit mode on their existing content types and sets up the drop zone library for them.

Sound good to have a drush command and/or wizard.

After diving and building a wrapper module (locally) for installing these features, I realized that the errors on installing is not a wrong-doing of the recipe. Involved modules has some problems. Recipe itself also need changes around included config in order to work for existing sites. I think this config should be moved in separate sub-module (or in existing as workaround), as edit_plus_landing_page for example.

I decided to take efforts to share a patches to fix current problems in involved modules, for manual install of all modules on existing sites to go successfully. Because after installing everything the features works really well, thanks Tim. And can be developed further without wasting a time adjusting installation process.
After this, recipes config for content type and fields should be moved, in existing sub-module, or in a new sub-module in edit_plus (edit_plus, just because other block/node sub-modules are there.)

There are some problems, which prevents installing necessary modules and sub-modules. I will create issue per module in their own with parent the current issue.

After the changes from the related issue MR, the recipe "config" content can be deleted.