tonypaulbarker → credited nJim → .
hestenet → credited nJim → .
I foresee some challenges with the current state of recipes that this sort of feature may address. In particular, there may be a need to map site-specific values to the configuration in the recipe. A few examples:
1. Avoid bloat when installing multiple recipes: For example, imagine a small business that is creating a site and wants to include a blog recipe, an event calendar recipe, an image gallery recipe, and a survey recipe. Individually, each one of these recipes may install functionally redundant configuration. A 'blog manager' role, an 'events calendar admin' role, an 'image gallery creator' role, a 'survey creator' role, etc. While it is valid for a user to have multiple roles, this can grow unnecessarily large. I can imagine a command line (or mapping file) that would prompt for things like the name of your content creator role.
2. Overcoming barriers with installing recipes on established sites: For this example, I'm a large, enterprise website that's been using Drupal for many years. I want to use a recipe that turns event content into different calendar feeds (rss, ical, and maybe some JSON standard.) I already have an event content type with named fields, so I don't want to create anything new in my data architecture. I just want to tell the recipe how to map the module's configuration to my content type. Typically we may create a layer of abstraction such as a module settings form or custom plugin. But in this case, I'm just interested in passing a few values such as the name of my content type to the script that is installing the recipe.
Just documenting as food for thought. There are multiple approaches to these issues.
I can confirm that typogrify on PHP 8.2 has deprecation warnings. I tested this patch on a fresh site install running PHP 8.2.
- All of the warning have disappeared.
- Reviewing code - all changes are consistant with other recent deprecation fixes.
- I functionally tested that Typogrify is replacing my hyphens with m-dashes as expected.
- Local tests are passing.
- Added automated test on this merge request for PHP8.2/MySQL8/D10.1 and the change passes.
This all looks good to me. Indicating this is reviewed and tested by community.
laura.gates → credited nJim → .
nJim → created an issue.