Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Seems like the interface in http://drupal.org/sandbox/webchick/1223824 would be much easier to build if we had a table from which to build it, which was re-populated on cron from time to time.
Upgrade Status module does what Update module does, and stores this info as a serialized blob in the cache table, and/or as strings embedded in the module. I need to yoink those out and store them for later consultation.
Here's a proposed schema:
nid ({node}.nid on drupal.org)
shortname ({project_projects}.uri on drupal.org)
name ({node}.title on drupal.org)
usage_count ({project_usage_week_project}.count for most current week)
usage_rank (Module's rank in terms of usage statistics on drupal.org.)
D6_release_nid ({project_release_nodes}.nid of recommended D6 release)
D6_release_label ({project_release_nodes}.version of recommended D6 release)
D6_release_date ({node}.created for recommended D6 release)
D7_release_nid ({project_release_nodes}.nid of recommended D7 release)
D7_release_label ({project_release_nodes}.version of recommended D7 release)
D7_release_date ({node}.created for recommended D7 release)
status (Status from Upgrade Status module.)
status_description (Status description from Upgrade Status module.)
status_notes (Notes from Upgrade Status module.)
checked (Timestamp of when this record was last checked.)
Comments
Comment #0.0
webchickClarifications.
Comment #1
webchickCommitted and pushed to master, with a few minor changes. http://drupalcode.org/sandbox/webchick/1223824.git/commitdiff/d82084c423...
Comment #2.0
(not verified) CreditAttribution: commentedUpdated issue summary.