as discussed at http://drupal.org/node/94154 it'd be great if something could tell site admins if any of their installed modules are out of date and if newer versions are available. this would have to be a contrib in 5.x, but it might move to core in 6.x and beyond...

to make this possible, the .info files for 5.x modules need to to include some additional information so that the check_updates.module (or whatever we call it) can find the project node on drupal.org to make the XML-RPC calls or find the right RSS feed for info about new releases for that module.

the attached patch appends this data to all .info files (just like we're already doing with the human-readable version string (http://drupal.org/node/97286). here's an example of the resulting signup.info file on my local test site:

; $Id: signup.info,v 1.1 2006/11/13 05:14:44 wright Exp $
name = Signup
version = "$Name: DRUPAL-5 $"
description = Allows you to signup for events or other kinds of content on the site.

; Information added by drupal.org packaging script on 2006-11-17
version = "5.x-1.x-dev"
Project name = "signup"
Project home = "drupal.org"

any complaints?

thanks,
-derek

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

merlinofchaos’s picture

IMO, 'Project name' and 'Project home' are perfect.

dww’s picture

Status: Needs review » Needs work

talked to dries about this. overall, he's happy with it, and basically said "you're the architect, do whatever you think is best". however, we hashed out some things both with the design, and the specifics of the data in the .info files...

  • he didn't like "Project " in front of everything
  • XML-RPC seems like the clear winner, but we don't know exactly it's going to be. probably a single XML-RPC handler where the client can post a big array of all the (name,version) pairs its got installed, to query "what's newer than this?". however, exactly where the XML-RPC handler will live (what URL, etc) is still TBD...
  • since we don't exactly know how things are going to work on the d.o + project.module case, and we certainly don't know how things are going to work for 3rd party sites, adding a "home" or "url" field is premature.
  • the project short name should probably just be called "project"
  • if the "project" is there, we assume it's d.o and will check, otherwise, we don't bother. this lets people turn things off (really, never enable them) for 3rd party modules, without making too many assumptions about how it's going to work in the d.o case.
  • we talked about adding a "type = [module|theme]" sort of field, but all of this is only being discussed for modules at this point, so again, the additional info seems premature.
  • in general, he's wary of putting in too much info we *might* want for fear of bloat and over-engineering.

so, the current proposal would look something like this:

; $Id: signup.info,v 1.1 2006/11/13 05:14:44 wright Exp $
name = Signup
version = "$Name: DRUPAL-5 $"
description = Allows you to signup for events or other kinds of content on the site.

; Information added by drupal.org packaging script on 2006-11-17
version = "5.x-1.x-dev"
project = "signup"

if that project = "signup" is there, the check_updates.module would know it's a d.o-packaged thing. it'd just have to have hard-coded knowledge of the proper xmlurl to use to query for the updates (presumably something like drupal.org/project/release/updates but we'll have to finalize that later). it'd have the (project,version) pair to send in the query.

basically, the only way to support the 3rd party case would be to do a more rigid thing in the .info file in the first place: adding a full-blown xmlurl field, not just a generic "home" where we conjure up the full URL, anyway. i think it's safe to just say we're only supporting d.o for now, and if someone wants to roll a whole system for another site, they can step up and i'll happily try to coordinate with them. until that happens, no sense over-complicating the common-case.

(setting to needs work since the patch is now stale from the current proposal, but i'm curious for more feedback on this before i plow ahead).

dww’s picture

Status: Needs work » Needs review
FileSize
4.9 KB

new patch that implements what seems to be the general agreement on how this should look.

i know the shell escaping stuff isn't exactly what some of the zealots prefer (escape at the last possible moment, depending on exactly how you're using the untrustworthy data), but i didn't feel like completely refactoring/re-organizing all the code. what's here is still secure, it's just less flexible if in the future we decide this script shouldn't be using shell commands (yeah, right). if that ever happens, we can reorganize all the escaping then. meanwhile, i have more urgent tasks to attend to.

so, any final complaints? otherwise, this is going to go live in a day or so. i already regret how many 5.x-* releases have been packaged without this.

-derek

dww’s picture

Status: Needs review » Fixed

after review from merlinofchaos, committed to DRUPAL-4-7--2 branch and installed on d.o.

Anonymous’s picture

Status: Fixed » Closed (fixed)