Drupal.org will have recipe browsing and a recipe browsing API at some point. For the results to be good, we need to know what recipes are popular.
Right now, we have download numbers for recipes, like https://packagist.org/packages/drupal/events_recurring/stats. Those numbers aren’t necessarily great since it measures when composer is run with the recipe as a dependency. And the key action for a recipe is its application, not download.
It would be better to have an API, similar to update status. So we have metrics for when recipes are applied.
The server-side is ready: https://updates.drupal.org/recipe-applied. Our CDN returns a static synthetic response immediately. Like update status, the data will be in query parameters and then we do log analysis to get useful data.
Conditions for sending data:
drupal/ namespace on Packagist.org, like https://packagist.org/packages/drupal/events_recurringData to send:
name recipe name, like events_recurringsite_key same arbitrary site key used by update status moduleThe final request will be like https://updates.drupal.org/recipe-applied?name=events_recurring&site_key...
Drupal does not need to wait for a response.
Decide on any opt in/out options. This is the same privacy policy as update status data. We don’t collect the site URL, don’t share logs, only aggregate, anonymous summaries.
Finalize any other data collected.
Once the final query parameters are set and in core, we can start on the server-side log analysis. The math will be a bit different since recipes are applied once, not installed.
If there is a new opt in/out UI.
None
Not for Drupal as a client.
n/a
To be determined
Active
11.0 🔥
recipe system
I'm not sure how the telemetry will work for doing the reporting, but I can say that there's a core event when a recipe is applied that is where we can know in code if it's happened and report it. Project Browser listens to that event here:
https://git.drupalcode.org/project/project_browser/-/blob/2.0.x/src/Reci...