Creating Your "Modules Portfolio"

Published: 3/18/2016

There are a ba-zillion contributed modules for Drupal that handle just about any common task you can imagine. Some modules are familiar to all of us - everyone's used Pathauto (opens in new tab) and Views Bulk Operations (opens in new tab), right? But there is also a wealth of niche, lesser-known modules you may have worked with - think Office Hours (opens in new tab) for adding business hours to an entity, Merci (opens in new tab)for equipment reservations, or Generate Password (opens in new tab) to auto-populate the user account password (helpful when authenticating via LDAP).

When you're documenting your own Drupal experience, or talking to other developers about theirs, you may realize you have more experience or preference for one module versus another for a similar task. For example, you may have worked extensively with Feeds (opens in new tab) for moving data about, but not as much with Migrate (opens in new tab), and not at all with Features (opens in new tab).

So after years of building Drupal sites and leveraging dozens of contributed modules, how do you keep track of what you've used and why?

A while back, I began keeping a list of contributed modules I've installed and used in my Drupal sites. I admit this was a manual process of updating an Excel spreadsheet each time I installed something new, but it became a part of my standard workflow, and it only took a minute to complete. My spreadsheet had columns for major version, name, and description. Not only was it a good reference for me, but other developers could quickly glance at it to see if a particular module was being used somewhere.

Now, there are some good arguments against manually maintaining a spreadsheet. One, it's manual; nothing in the process is automated. Two, such a spreadsheet should never be used as a definitive list of modules (too much chance for human error). And three, obviously, Drush already provides this basic functionality through the pm-list command.

But despite these drawbacks, here are some reasons why I continue to keep a manual list of modules I've used as a supplemental reference.

Retired sites

Guess what you can't do with a site that doesn't exist anymore? You can't run drush pm-list against it.

If you've worked with Drupal for a long time, inevitably you've built sites that became irrelevant, were replaced with another technology, or simply weren't needed any longer. A great example of this is the Cloud Document Sharing site (opens in new tab) I developed many years ago. At the time, there was no easy way to share documents and version changes with resources outside of our organization. We experimented with different technologies, but nothing quite met our functional and security needs. However, a Drupal Site running File Depot (opens in new tab), Organic Groups (opens in new tab), and other contributed modules provided exactly what we needed. For a while.

Eventually, Office 365 delivered all of those features through OneDrive, Teams, and Sharepoint on an enterprise-wide scale. So, the Cloud site was retired and ultimately removed.

Guess what you can't do with a site that doesn't exist anymore? You can't run drush pm-list against it.

No access to Drush/CLI

I know that some developers can't imagine this, but there are web servers that don't have Drush installed and hosts that don't offer command line access. Whether or not this is ideal doesn't matter. It happens.

So, once again, drush pm-list is useless for getting a modules list.

Preferred fields/metadata

It's great to have a list of module names, but what about descriptions (the one-liner in the module info file that describes the module's purpose)? What if I want to record other information? What if I don't want sub-modules in the list (I want to see Webform, but not Webform UI)?

At least as of today, Drush 9 doesn't appear capable of outputting a description or limiting the list to sub-modules. It looks like this was an option with the pm-projectinfo command in prior versions, but that's been deprecated in favor of pm-list. And, of course, none of these commands can add my personal notes or comments.

Conclusion

For now, I'm keeping my manual record, and I think other developers should, too! What better way to showcase the diversity and range of projects you've worked with? It can serve as a tool for your own reference, as well as prospective employers and clients.

But...maybe it can be more a little more sophisticated than a Excel Spreadsheet. Maybe it can be content in your portfolio site. Maybe it can look something like this...

My Contributed Modules Portfolio (opens in new tab)

Haha, just kidding. ^^This doesn't exist anymore^^