I am constantly wishing there was a simple table that has a row for each module and a column for each major release (i.e. "4.x", "5.x", "6.x", "7.x") the cells showing at a glance whether a module is available for that Drupal version.

The cell could contain an abbreviated copy of the release information as found in the individual module sections i.e. version number with green colouring if there is a live release, version number with red colouring if there is only a dev release available, "n/a" and no colouring if there is no version available for that Drupal version (or if there is only a head release etc.).

This would substantially increase usability of the already good version information and, for instance, allow designers and developers to quickly see what version of Drupal they should create a site in or which design approach to use. It would also save a bit of site traffic as I imagine the current alternative of everyone viewing the filtered "Browse by name" pages are one of the sites heaviest page usages.

Comments

oadaeh’s picture

oadaeh commented

I suspect what you are asking for would load and display at something like the rate this page does: http://drupal.org/project/issues/subscribe.

While I think what you are asking for is a neat idea, and one I would probably persue myself, I really don't think it will help at all with the load of the site.

If, for example, what you are looking for is a visual clue of which modules are on version 6, then a better option for site load reasons would be to choose the 6.x filter at the top of all project listings.

John Bryan’s picture

John Bryan commented

Just to expand a bit 8¬)

Re: "would load and display at something like the rate this page does:"

Yes it would be a slow load page, but (if populating by SQL query as opposed to node listing) still probably faster than "Browse by name" tab without a filter. And certainly faster and less loading than a "Browse by name" with 4.x filter followed by a "Browse by name" with 5.x filter, followed by a "Browse by name" with 6.x filter. Also faster and less loading than a "Browse by name" with 5.x filter followed by numerous opening of individual project nodes to see if they are available in 6.x.

Re: "a better option for site load reasons would be to choose the 6.x filter at the top"

This is explicitly what I am suggesting a replacement for (for certain tasks). It does not:-
- Give a comparison
- Show what modules are not available to 6.x
- Give something that can be practically printed out as a reference

I would be certainly interested in anyones attempt to do this, especially from within the drupal.org site - unless read only SQL access to the Drupal.org DB is available for external sites.

ac’s picture

ac
Primary language English
Location Perth
commented

I would suggest reading this post (http://groups.drupal.org/node/6186) and getting involved there. Alternatively you could post a feature request under the project.module issue tracker. This request is likely to fall on deaf ears here.

aclight’s picture

aclight commented
Project: Drupal.org site moderators » Project
Version: » x.y.z
Component: Site organization » User interface
Status: Active » Closed (duplicate)

This is a duplicate of #63491: Drupal Version-Module Support Matrix.

In addition, the D6 version of the project module will likely use paged browsing for all types of browsing, so the performance problems related to the Browse by name method should not be an issue any more.

John Bryan’s picture

John Bryan commented

DOH!

Posted in the wrong area 8¬{

I thought I was posting a feature request for the "Drupal" Project - but I have posted in the "Project" project. Thud, thud, thud {hollow sound of head banging against the wall}.

aclight’s picture

aclight commented

No, you originally posted this in the Drupal.org webmasters queue. However, this feature would need to be implemented in the Project module, which runs on drupal.org. Therefore, I moved it to the project queue, and marked this as a duplicate.