Add tracking for when recipes from Drupal.org are applied

Add version data to send

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...

Tagging as a Drupal CMS release target. If we were to implement this in update module, would that save an additional opt-in? It's almost exactly the same data that we already send from update module so might be fine. Then update module needs to do something with the event - would suggest adding it to a queue item, and then having the queue runner actually send the data so it's as light as possible when applying a recipe.

I would suggest that we simply add this to the Update Status module as an event subscriber, respecting its opt-in/out.

+1 to recipes calling home for update status.

I was thinking about this a bit when the site templates concept was described. D.o gets directionally accurate stats about module and theme installs based when the available updates call home. That's a little more accurate than composer downloads, and it would align from an accuracy standpoint to our other metrics.

We kinda need this sort of telemetry for Drupal CMS install metrics as well. If recipes called home about updates, we could use drupal_cms_starter as an indicator that at least part of the site was based on Drupal CMS. As it stands now, we can only guess at Drupal CMS installs based on one of the dependent feature modules with drupal_cms_ in the name.

One drawback to recipes calling home is that it kinda assumes that recipes will be added to a site and not removed. That might not be a best practice as many recipes will not continue to apply as a site develops over time.

there's a module for it:
https://www.drupal.org/project/recipe_tracker →

One drawback to recipes calling home is that it kinda assumes that recipes will be added to a site and not removed. That might not be a best practice as many recipes will not continue to apply as a site develops over time.

I think it would only every be sent to d.o once, not like modules which are every update status check. So it would be possible to track the cumulative times a recipe has been applied, and month by month comparisons, but different from current project usage stats.

I wonder about a scenario in which a recipe is applied multiple times because it might be a dependency for many other recipes. That would be a common case for starter/base recipes. Said recipes can be deduplicated, which is an approach the recipe installer kit is promoting, or simply applied multiple times. The main issue I see here is inconsistency, which results in slightly off telemetry data.

Re #5: while I agree that the proposed approach is clean, I wonder how this could be respected if the recipe is applied via installer (no option to opt-in/out) or the site is installed from the recipe (drush si ../recipes/drupal_cms_starter).

Re #7: Recipe Tracker (thanks for mentioning it here) is meant to track the application of recipes locally, within your Drupal instance, and never sends any data outside the Drupal instance context.

The issue summary mentions including the update status site key, which is used to de-dupe update status data per-site.

We will have to decide on a new algorithm for translating the recipe application numbers into popularity for ranking. Something along the lines of including the last N weeks, potentially with some decay function so the last week contributes more to the rank, and each earlier week contributes less. Until we have some real data, it isn’t worth much speculation about the specific implementation. The earlier we have data, the better.

Additional metadata that might help is welcome, as long as it doesn’t send identifying information about the site, or delay initial implementation in core. Adding method of installation to the query string with the request would be useful - installed via installer, project browser, drush, as a dependency, etc.

@zaporylie it might be possible to add recipes to a queue in the installer, and then run through the queue on first cron run when updates status is either applied or not.

I don't think we want recipe application itself to trigger an http request to Drupal.org, so also going via a queue might be a good idea anyway. We can make it clear in the documentation for the hook/event that it's triggered an indeterminate amount of time after the recipe is applied.

I appreciate the feedback in #10 and #11. Routing recipe application d.org update requests to the queue, with the update module acting as the queue consumer, sounds like a clean approach that respects global tracking settings.

I’m curious about one more thing — the issue summary mentioned the name as one of the properties featured in the request. I’d like to clarify two points:
- The recipe directory name—which is essentially what the recipe name comes down to—has only a loose connection with the project on d.org. I believe we should only send an application update if the recipe includes a composer.json file, so we can verify that it belongs to the drupal/ namespace as outlined in one of the conditions in the issue summary. This would filter out all custom recipes added at the project level (i.e., not available on d.org even if the recipe name matches a general project on d.org), as well as recipes under other vendor namespaces.
- This also means that all core recipes would never be tracked. Are we okay with that, or should we support core recipes too? If so, we’d need to collect version information from the drupal/core package.

- The recipe directory name—which is essentially what the recipe name comes down to—has only a loose connection with the project on d.org. I believe we should only send an application update if the recipe includes a composer.json file, so we can verify that it belongs to the drupal/ namespace as outlined in one of the conditions in the issue summary. This would filter out all custom recipes added at the project level (i.e., not available on d.org even if the recipe name matches a general project on d.org), as well as recipes under other vendor namespaces.

That sounds correct to me.

- This also means that all core recipes would never be tracked. Are we okay with that, or should we support core recipes too? If so, we’d need to collect version information from the drupal/core package.

Yes, we do want core recipe information, so that will need to be a special case.

All of this sounds good to me. Only thing that I take a quick note of is that we already have the "dependency popularity" problem with modules... Chaos Tools being one of the top-installed modules... that users almost never care about.

Our consideration for this was to maybe allow projects to opt into a checkbox like "library-only" and then hide those from PB's default filters (allow them to be shown if the user wants that).

Not sure that applies to recipes, as most base recipes ARE "useful unto themselves," so maybe it's different. Anyway, just a little something to consider/think about.

We’ll handle any browsing requirements at 📌 [Meta] Plan for recipe Active . For now, we just need the data as soon as practically can be done.

(Off-topic - I took a quick survey of Drupal.org’s modern sites, the only reason we install ctools is pathauto, https://www.drupal.org/project/pathauto/releases/8.x-1.11 → it’s general popularity should decrease, but that will take years.)