Proposal: Module Category Guide for Drupal 7

As all of us who have been playing with Drupal 7 have seen all the changed in its user interface. Not only have things been moved around, many features have also been renamed. This has resulted in a much more logical user interface, especially when it comes to administration of a Drupal based website.

Once you get over the first dizziness of feeling lost in the new structure you will appreciate the changes as you will be able to work more efficient.

Some smart improvements to module management has been made, especially on the Available Updates page where you now both can see which sub modules are enabled/disabled for each module as well as if there are new versions of disabled modules. Both these improvements are highly welcomed.

On the modules page though, it is still chaos. Here on Nutshell I am currently using 14 contributed modules and as far as I can tell they all use the same categories as their Drupal 6 counterparts. Most of them using the "convenient" Other category.

The Package field in [module].info

In the description for the "package" field in the [module].info file it says:

In general, this field should only be used by large multi-module packages, or by modules meant to extend these packages, such as CCK, Views, E-Commerce, Organic Groups and the like. All other modules should leave this blank. As a guideline, four or more modules that depend on each other (or all on a single module) make a good candidate for a package. Fewer probably do not.

When the package field was added the number of contributed modules for Drupal was much much less than the 7,000 or so that there is today. Thus the intended use of it was clear.

Now when there are so many more, and tens of new modules added every week, I suggest it is time to find a new way of organising them on the Modules page.

It would also go in line with the other changes to the user interface in Drupal 7, which is now much more organised based on what the features are used for.

The main problem with the package field, as I see it, is the guideline about it should be four or more modules that depends on each other for there to be a new package name. For modules such as Views, Display Suite, etc that is of course not a problem. Now though when many modules, such as CCK and ImageCache, to name two, is in core, we are going to see a lot of new much more focused modules using these new core API's.

The current guideline also makes It quite difficult for a module maintainer to easily identify any existing package name that is suitable for their module. In most cases this ends up with that they leave it out and their module ends up among all other modules in the Other category.

Using "package" or Adding a New Field Name?

There are two ways of offering a more logical list of modules:

1. Redefine how the package field is used.
2. Add a new module "category" field.

Redefining how the package field is used in Drupal 7 have the advantage that no code changes are needed. The modules list will work and be presented as I outline below. The negative part is that the name "package" isn't the correct term to use.

Adding a new field this late before the release of Drupal 7 is not optimal either, but since it will only affect how the modules are listed on the Modules page, it is something that wont affect any functionality.

One way of doing could be the use "category" as a synonym to package and then depreciate package in Drupal 8.

In the proposal below I will use "category".

Proposal for Module Categorisation Guide

Using the categories as on the www.example.com/admin/by-task page (same as the links in the top Admin toolbar) would be a great start.

• Appearance - Modules that adds features for how a site looks for visitors as well as features used by content editors. This includes for example the WYSIWYG module.
• Configuration - Modules that improves the administration and configuration.
• Content - Modules that improves the content management.
• Modules - Modules that improves module management.
• People - Modules that adds features for user management, roles and permissions.
• Reports - Modules that improves or adds features to statistics and other reports based on Drupals own logs.
• Structure - Modules that adds features to the structure of pages for users. Such as the Comment Notify module.

Some of the above categories will end up containing a lot of modules. Especially this is true for the Structure category since modules such as Views, Display Suite, Panels, etc would all end up there.

I see these modules as both containing ready to use features as well as providing API's to make it easy to add sub modules to them. Then we can simply use the category format "Structure - [Main Module]" and we would end up with:

• Structure - Views
• Structure - Display Suite
• Structure - Panels

Then we have other groups of modules that would make good candidates for sub categories. One example is:

• Structure - Social Media - Modules that adds features for users to easily share information from the site, or adding features to integrate social networking. AddThis, Twitter, Follow would be found here.

This would make a nice and clean module page where it will be very easy to locate the modules.

Additional Categories

The above categories are based on Drupal Core and is a good start for cleaning up the list. Then there are lots of modules that wont fit into the above and additional categories will be needed for them.

Some ideas for new categories:

• Development - Modules providing features only for development servers.
• Search Engine Optimisation - Modules specifically designed to improve SEO, such as XML Sitemap, Nodewords, etc. This can be a bit tricky as many modules also would fit under structure, such as Pathauto. An alternative might be to use Structure -  SEO.
• Analytics - Google Analytics and similar modules for managing external traffic analytics.

There will of course be other categories needed, but I am sure you get the general idea with my proposal.

Easy to Implement

Since this proposal only affects the grouping of modules on the Modules page, and not any functionality, it would be easy to implement. If the package field would be reused for it, no new code is needed.

The result would be a much more logical and better structure in the module list, especially when the number of modules on a website is growing.

I for one would be very happy if the module list was better organised. Wouldn't you too?

Update 22:35: I missed the bit about how the package field is supposed to be used, my proposal is therefor rewritten to reflect that.