Want to contribute back to the Drupal community? Don't be afraid, Git is not as hard as you might think. There are plenty of resources available to those who search. Drupal recently switched over to Git from CVS. Much of the documentation on Drupal.org is out of date, so if you see documentation related to CVS, remember that Drupal now uses Git.

This post will serve as a way of helping you to get involved in the Drupal community and contributing modules back.

Get Git Access

I've just released version 2.3 of the Sites module, which has been quietly under off-and-on development for a couple of months now here at EchoDitto Labs. Sites was originally conceived as a way to make it easy to create multi-site Drupal configurations without the problems and complexities incurred by using Domain Access. Sites is a less-articulated solution than Domain Access: it has fewer features at present, and does not integrate as deeply into the Drupal access stack, but is consequently more stable. Most importantly, it avoids rebuilds of the node_access table, which can be slow (and, in the case of very large sites, can even cause your servers to grind to a halt).

There are several considerations that came into play in the decision to write the module. First, we wanted to be able to create multi-site installs of Drupal wherein some views could show content existing across sites, while others could discriminate between those sites and show only content from the current site. If we simply created a new folder under /sites, there would be no clean way to know at the level of the controller (nodeapi, Views, etc) what site was being used to access content. Furthermore, if we decided to segregate content into different databases, it would be difficult to share that content across sites (the easiest alternative would probably be to publish feeds, which seemed like far more trouble than should be necessary).

This week, I released a Drupal 6 module called Environments (shortname Envts), my first released module and EchoDitto's first for Drupal 6. Its purpose is to help developers manage "two-dimensional" Drupal site environments. Drupal is fairly good at running multi-site builds, with sites folders and different settings.php files. Modules like Domain Access are good at managing those sites one-dimensionally - a single list of hosts with primary (mysite.com), secondary (special.mysite.com), etc, and deep integration with Views and other modules.

But this single list of sites is built for one environment: one set of domains, such as for a live site. For example:

• dartcenter.org [primary]
• dartsociety.org [secondary]

Domain Access is good at listing these domains and filtering nodes by them. But in our work, there's never only one environment. There's a development environment -

• dartcenter.dev.echoditto.com [primary]
• dartsociety.dev.echoditto.com [secondary]

- and each developer usually has a local server environment -

• dartcenter.ben.local [primary]
• dartsociety.ben.local [secondary]

- and sometimes there's a staging server between dev and live -

• staging.dartcenter.org [primary]
• staging.dartsociety.org [secondary]

- and so forth.

I've had a couple projects that needed the menu system to stay open when a full node was being displayed. The Drupal menu system, while dynamic and mostly awesome, didn't seem to allow for that, at least not in the way that I needed it to. So, I wrote Automenu.

For each content type, Automenu allows an administrator to set a default parent in the menu system. If a node is given an entry in the menu system, that default parent is ignored. Relatively simple.

To illustrate, let's say you'd like all nodes of type 'news' to show up under an entry in Primary links called 'Newsroom,' but you don't want to actually create an entry in the menu system for each one. Automenu will do that for you, specifically without creating additional entries in the menu system. If you want to give an individual news node its own special place in the menu system, you can still do that the standard way.

Give it a shot!

Thanks to merlinofchaos and the folks in the #drupal IRC channel for steering me in the right direction on this. They're a bunch of great and helpful folks.

Some of you may remember opensource.echoditto.com, EchoDitto's lately-neglected repository of free software. We've had turnover both in staff and Drupal versions since the last time we paid serious attention to it. One of the goals of this labs project is to migrate that software over.

Much of it hasn't been ported to Drupal 5 — and most of it shouldn't be. Webform makes echoinvite unncessary; askismet and the spam module encompass the capabilities of blacklist.

But we've still got a few useful tricks up our sleeves — and now have some new and improved, Drupal 4.7 and 5 versions of "classic" EchoDitto modules.

So, first up: EchoDump. This is an awfully simple module, but also an awfully useful one — at least in my experience. If you're maintaining a Drupal site for a client that expects regular reports but isn't capable of wrangling with SQL, this can greatly simplify your life. It allows you to create SQL reports that can be exposed on a granular basis to users. And it features easy exporting to Excel, making the creation of "user signups over time" graphs and the like a relatively painless process.

As you might expect, you'll want to be very careful about which users you grant the right to enter SQL.

Also, please note that although the 4.7 version has been used on production websites, I just adapted it to 5.0 for this post. Please consider it beta software, and use it with care.