Problem/Motivation
I am writing a module that helps module maintainers keep track of the usage of their modules. The data source that I have been able to find is this:
https://www.drupal.org/jsonapi/index/project_modules?filter%5Bmachine_na...
The response has the following properties/values inside "data" > "attributes":
"field_active_installs": "{\"8.x-3.x\":1671,\"8.x-4.x\":2,\"5.0.x\":2709,\"5.1.x\":7914}"
"field_active_installs_total": 12296,
However, as far as I can tell, it doesn't provide a way to get historical data about project usage, as you can see on the https://www.drupal.org/project/usage/charts page.
Steps to reproduce
See above.
Proposed resolution
Remaining tasks
User interface changes
API changes
Data model changes
Issue fork drupalorg-3560293
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
fjgarlin commentedThis was a conscious decision introduced in #3498849: Project usage totals should exclude Drupal 7 branches.
Comment #3
andileco commentedSorry, I didn't mean any D7, just more than a single entry for 5.1.x, for example.
Comment #4
fjgarlin commentedSingle entry for specific releases is not an option, but you can parse the field and store it as you need:
For example:
Produces:
Comment #5
fjgarlin commentedSorry, I get what you are asking now.
You mean weekly data for each branch. That information is not stored as part of the entity itself, it has a separate table.
I guess we could do something like #3559622: Provide way to access all projects maintained by a user, where we create a new endpoint with custom parameters.
Comment #6
fjgarlin commentedI've put some WIP I've been experimenting with just to see if we can reuse some code. I will continue work on it in the coming days.
This will also conflict with the other mentioned issue, so I will fix that once the other is deployed/merged.
Comment #8
fjgarlin commentedI'm happy with the logic here to be reviewed, but as mentioned before, this #3559622: Provide way to access all projects maintained by a user should go first, and I will fix the conflict once merged.
The endpoint will be something like
/drupalorg-api/project-usage?nid=3060[&weeks_ago=10]If no "weeks_ago" param is given, it will be all-time data.
The output will be split by weekly timestamps:
Comment #9
fjgarlin commentedFeedback addressed.
Either this or #3559622: Provide way to access all projects maintained by a user can go first and then I'll adapt the other. I don't think it really matters the order, so if this one is ready before it can be merged.
Comment #10
drummLooks good to me
Comment #12
fjgarlin commentedThis is now merged. It will be deployed today.
Comment #14
fjgarlin commentedDeployed.
Example, webform usage for the last year:
https://new.drupal.org/drupalorg-api/project-usage?nid=7404&weeks_ago=53Note that querying all time data for big modules might incur in timeouts when accessed via web (5xx errors).
Comment #15
andileco commented@fjgarlin, I believe there is a data issue with this. I went to look at Charts: https://new.drupal.org/drupalorg-api/project-usage?nid=232629&weeks_ago=2
Here were the results for me:
The results here (https://www.drupal.org/project/usage/charts) are:
Thank you!
Comment #16
fjgarlin commentedTrue! Thanks for reporting. I took some of the logic for the individual weekly jobs, but it was multidimensional arrays, so I'm sure that I forgot to reset something somewhere. Looking into this.
Comment #17
fjgarlin commentedFound the issue! We were literally looping the loop on numbers!
Commit: https://git.drupalcode.org/project/drupalorg/-/commit/eadec4681ee355fcab...
Deploying shortly.
Comment #18
fjgarlin commentedNumbers here https://new.drupal.org/drupalorg-api/project-usage?nid=232629&weeks_ago=2 match exactly what we see in comment #15.