🇺🇸United States @thejimbirch

Sadly marking as RTBC. Looks like it was removed from all the places.

thejimbirch → created an issue.

Fantastic idea. Changing this back to needs work.

Tried the updated MR on that branch, but getting different errors now. Will have to circle back on this.

thejimbirch → made their first commit to this issue’s fork.

Would this be resolved by creating our own separate recipe for our desired text format, so that other recipes could apply it as needed?

Yes. Since the Drupal CMS starter recipe hasn't defined a text format, the tracks have had to require their own dependent formats. If it were to be defined that all recipes must use recipe x text format, we could have consistency.

Thank you

Closed (duplicate) usually has a reference to the issue it is a duplicate of.

Marking as RTBC. There is a considerable difference with the patch applied.

Starting a site with the Minimal profile and then applying Drupal CMS Starter recipe.

ddev drush si minimal -y
then
ddev recipe-apply recipes/drupal_cms_starter

With patch -> 51s, 52s, 53,
Without -> 1m 28s, 1m 27s, 1m 29s

==============

I ran a second test, and drush site:install with the standard recipe and it was a second faster also.

ddev drush si core/recipes/dtandard -y

With patch -> 9s, 8s,8s
Without -> 10s,10s,9s

thejimbirch → changed the visibility of the branch 3481929-add-input to hidden.

johnpicozzi → credited thejimbirch → .

johnpicozzi → credited thejimbirch → .

Thanks for the suggestions. They have been applied and the branch rebased.

thejimbirch → created an issue.

Merged. Thanks for your contribution!

Needs change order and documentation issue follow up.

Thanks for the merge!

thejimbirch → created an issue.

thejimbirch → created an issue.

Not postponed, both are related to the Drupal CMS Dashboard track.

Same here, this recipe exists in contrib. Why not require it from there so you don't have to maintain multiple versions?

Why not just require the recipe you maintain in contrib? https://www.drupal.org/project/events_calendar →

Are you going to end up maintaining it in 2 places?

Tests were added and Mr tests pass. Marking as rtbc.

The MR applies and adds a new module and schema form for ProfilePage. Works as designed. Marking as RTBC. Thanks for the contribution!

Should there be a follow up issue to update documentation and the Schema WebPage module to recommend using ProfilePage instead?

This is so cool! I believe this is the first contib config action.

1. As a general best practice in recipes, we strive to make recipes/config actions non-destructive. Will removeDatasource, removeProcessor, and removeField present the possibility of a recipe breaking a site? What would those actions be used for?

2. Could we get a change order for this issue? As the first config actions in the contrib space. It would help with documentation in the Recipes Initiative and set precedent for other contrib modules to follow.

Something like this (Note: I am not sure that is how the actions work)

## Search Index

### `setOption/SetOptions` - Set index option(s)

Singular:
```
config:
  action:
    search_api.index.example:
      SetOption:
        cron_limit: 50
```

Plural:
```
config:
  action:
    search_api.index.example:
      SetOptions:
        cron_limit: 50
        index_directly: true
        track_changes_in_references: true
```

### `removeDatasource` - Remove datasource from index

...

### `removeProcessor` - Remove processor from index

...

### `renameField` - Rename index field

...

### `removeField` - Remove field from index

...

## Search Server

### `setBackendConfig` - Set backend config

I am unable to rerun the pipeline.

This looks good, but tests are failing. I believe unrelated as this has no tests.

Speaking of which, does this need tests?

thejimbirch → created an issue.

Removed #3452652: Recipes in Drupal core should have a logo for findability in Project Browser/Starshot as Drupal CMS will not show core recipes in Project Browser.

Un-postponing then as this is a Drupal core issue, not a Drupal CMS issue.

PHPstan level 9 and Test are still failing.

I created ✨ Create a setVisibility config action to change a block's visibility Active as the proper approach to solve the issue presented here.

Closing this issue as the clear approach undoes what other actions might do, and goes against recipes goal of being non-destructive.

thejimbirch → created an issue.

Made some small nits.

Closing as #3284701: Allow recipes to assign config provision authority to extensions → was fixed.

Updated the documentation.

With the introduction of config:strict → in 10.4.0+, there is a way to allow leniency in config import that is much safer to use than createIfNotExists

config:
  # The default.
  strict: true 
  # If any config exists, skip them.
  strict: false
  # Ensure some configs are the same. 
  # All others are false.
  strict:
    - field.storage.foo
    - taxonomy.vocabulary.bar	

Updating the documentation based on this.

There are merge conflicts. Moving back to Needs Work.

thejimbirch → created an issue. See original summary → .

Thanks for this. The patch works. Updating to the 4.x branch as the 2.x is now deprecated. +1 for RTBC

Drupal 11.1 comes out soon. Any chance the maintainers could add a new release that supports Drupal 11?

Thanks for your contribution!

nicxvan → credited thejimbirch → .

I made a couple of small nits on the MR. For the Wiki, I think more information should be provided around:

Requires an X11 server running on the host machine such as XQuartz on macOS.

It may be common knowledge, but I didn't know what an X11 server was, nor did I know what XQuartz was before trying to install the ddev addon. There are some more steps that are also needed I believe. There is an ongoing discussion on the setup here: https://github.com/tyler36/ddev-cypress/pull/38

thejimbirch → created an issue.

Subfolders are not currently allowed. The recipe runner only looks for recipes in a sibling folder. Allowing subfolders could lead to naming collisions as you could have a content_type_page in multiple sub-folders and which one would a recipe that depends on it apply?

So we change type to have 3 different options.

Foundational - Simple recipes that provide reusable configuration primarily for other recipes to reuse.
Kit - Recipes that provide a complete functional solution for a site feature (SEO tools, event calendars, workflows, etc.).
Site - Recipes that provide complete website starter solutions like what Drupal core's Standard recipe provides.

1. Do we need a second classification type to cover the Foundational descriptive types that we currently have defined? (Text format editor, Content type, Taxonomy, etc)

- or -

2. Do we assume that if it is one of the existing type (Text format editor, Content type, Taxonomy, etc) that it is Foundational?

No. The types are still defined in that document as part of the best practices.

Merge request added that updates the types/naming doc.

thejimbirch → created an issue.

The patch in #19 has _bootstrap_paragraphs_check_for_bundles. I don't see that anywhere in the applied file.

You also linked to the 5. branch. This is for the 8.2 branch.

Great to catch a few potential bugs! Marking as RTBC

Could I switch to using core’s recipe?

thejimbirch → created an issue.

Looks good to me.

griffynh → credited thejimbirch → .

thejimbirch → created an issue. See original summary → .

thejimbirch → created an issue.

Amazing! Marking as RTBC.

We will need to update the docs and I assume this should have a change record also.

Looks good. Marking as RTBC assuming tests will pass.

I don't see the benefit of moving it. You would then have to require menu here which all content types do not need. I feel like you could just change the weight in the base seo recipe.

I was mid review when things vanished on me. The only thing I could see would be the optional node views. You are calling them in the Drupal CMS base recipe and that is the only thing you need node there.

This will also be the place to keep field storage configs to be used by all recipes.

Some changes requested around the redirect module.

thejimbirch → created an issue.

Doh is me! Sorry about that folks, We did fix it in the beta10 tag, but never cut the release.

I just did. Changing this to fixed.

Thanks for the follow through.

In principle this seems okay but I'm a little conflicted that it should be its own recipe. It's a very small piece of the overall Drupal CMS puzzle, and frankly these redirects are things that should be fixed in core anyway. Adding more recipes increases complexity and maintenance burden, albeit not by much...but it adds up.

It is a very small piece of the Drupal CMS, but one that provides a foundation and example for using ECA instead of custom code or more contributed modules that needs to be maintained.

It indeed adds some maintenance burden for Drupal CMS , but I worry that that line of thinking will make the base Drupal CMS recipe too opinionated. The fact that ECA's are saved as config entities make them shareable and repeatable. Allowing this small piece of functionality to be its own package would benefit and lower the maintenance cost for the community with being able to require and use instead of copying and pasting.

In the Recipe Author Guide's Guidelines for interoperable recipes it is recommended to

Put reusable config in its own recipe.

As a rule, where a config entity is applicable to many different use
cases, it should go in its own recipe....

thejimbirch → created an issue. See original summary → .

thejimbirch → changed the visibility of the branch 3481929-document-recipes-can to hidden.

thejimbirch → changed the visibility of the branch 3481929-document-recipes-can to hidden.

thejimbirch → created an issue.

So maybe this should be postponed?

Makes sense.

... we could change the recipe to ask which content types to add the fields to, all, or specific bundle machine names.

I was wrong. Reading the change order → , it is not currently possible.

And you can't do things like:

config:
actions:
node.type.${content_type}:
# ...some nefarious business...

This is not allowed because it would make the recipe's effects less predictable, and therefore less composable, which would violate a fundamental design principle of the recipe system.