I don't know if this feature request should be against the Update Status module, or drupal.org itself, or both, but it would be extremely useful to know more information about modules that need updating. It would be good to know:

1) if a module requires special installation (ie. tinyMCE's two-step install). This could be provided such that the module maintainer could choose "standard install" (copy module to modules folder, enable), "special install requirements", with a text box for details on those requirements, or "standard with post-install setup requirements" for modules that have a standard install process, but require extra set up to actually work once they are installed.

2) if a module has prerequisite modules, and list what they are. Also list the latest version for these modules.

And display all this information in the admin/logs/updates page.

This information is probably going to be required for any fully-automated module update process in the future, but before that it would be extremely useful for updating sites with lots of modules.

Comments

dww’s picture

dww
we/he/they
commented

Yeah, it can be against update_status.module. However, now that update_status is in core, it's harder to add new features to it. :( New features now have to be added to the following places:

update.module in D7 core
Update advanced in D6 contrib
Update status in D5 contrib

How's that for confusing? ;)

Both of these would require changes to the schema of the XML files that update_* fetches from drupal.org. I'm weary to add more data to those, since pruning the amount of data is one of the goals of #238950: Meta: update.module RAM consumption, which is a higher concern for update_* right now, anyway.

naught101’s picture

naught101 commented

It would basically be two lines: 1 for install type (I don't suggest including install instructions, since a link to the module page is already included), and 1 for prerequisites (which are included in the module.info). Would this really have a large impact?

Where can I see such an XML file?

dww’s picture

dww
we/he/they
commented
Status: Active » Postponed

http://updates.drupal.org/release-history/signup/5.x is an example XML file.

The other problem here is that the script which is generating those XML files is currently able to do everything it needs via the DB. Having to parse .info files would add a huge cost to this script, since it'd have to check out every release individually, parse the .info file, etc, etc. What a nightmare. We *might* parse the .info files during packaging (see http://groups.drupal.org/node/11998) for other reasons, in which case maybe the dependencies will already be stored in the DB. But, that's yet another can of worms to consider.

Given all that, I'm going to call this postponed until #238950: Meta: update.module RAM consumption is done, and probably http://groups.drupal.org/node/11998 too.