So what have we accomplished? We can now override the value of the items per page in the blog view without overriding the feature. Furthermore, we can also export a new feature that encapsulates this change. Since the configuration is held in a variable, we can use strongarm to export that variable into a feature of its own. For example, we can have a feature called siteb_blog that has a dependency on tha_blog and a variable to override the items_per_page.

Great walk through of how the folks at Funny Monkey deconstructed a site to turn it into several types of Features so that it could be easily plugged together and managed as an install profile.

Contrary to the hopes of some, Drupal Commons should not be mistaken for a user-focused social network. Instead, Commons is aimed at large companies, and it is a great choice for that audience. I also foresee Drupal Commons being particularly useful for in-house developers with less Drupal experience and for small- and medium-sized companies looking to use Drupal as a springboard for building better relationships with their users.

A very thorough write up of how Acquia Drupal Commons came to be.

It is very much is targeting Jive and Telligent, with similar thought processes behind it, which I think is a shame. I don't find these types of enterprise social networks very interesting, and would like to see more evolution in the space.

Obviously, there is a customer base still clamouring for these type of solutions, and I'm sure with the open source advantages and library of other modules, we'll see some adoption by large companies.

Patches that we write for drupal.org modules are submitted to the issue queue, and we refer to the patch’s location on drupal.org in the make file. This has made us much better contributors to other people projects as it makes being involved in the issue queue a normal part of development, and it encourages us to only patch contrib modules where it’s likely that the patch will be accepted. When a patch gets a review, we make changes, upload a newer version of the patch to drupal.org, and update our make file.

via developmentseed.org

This is actually a quote from Jeff in the comments on the article Drush Make Files for Production Drupal sites, but I thought it was definitely worth highlighting on its own.

In this particular case, using make files actually codifies the decision to integrate closely with contrib modules and actively improve them / add features as needed for a particular project.

I've followed this practice for years, albeit without make files. Patches go in a "patches" directory in version control, with the patch file named with both the name of the module and the node number of the issue on Drupal.org.

An additional process is that if a patch is needed, you run it in the issue queue on Drupal.org, but you also have an internal ticket that links to that issue. You don't close the issue until the patch has been accepted into the mainline of the module. Then you can remove the patch, update the version of the module you're using, and your clients' website is one step closer to easier long term maintenance and updates.

And yes, being involved in the issue queue SHOULD be a normal part of developing Drupal websites.

Shared Web Hosting - BlueHost supports both the Drupal and WordPress open source projects, and is a recommended host for both.

For many years, I've settled on Unfuddle as my hosted tool of choice for development-focused project management and version control repo hosting. It's a great tool if you want all in one development ticketing / bug tracking (which is what I mean when I say "dev focused" PM) plus your code repository all in one place.

However, I've been moving away from using Unfuddle for this type of project management, or been called into other projects where an existing PM tool is already in place -- most notable, either Basecamp or Open Atrium, with the Drupal-based Atrium being something I'm very keen on supporting (interested in seeing more hosted tools integrated with Open Atrium? contact me).

In cases like this, I really ONLY need a (private) hosted code repository*. I saw an article recently comparing various options for private DVCS hosting (DVCS = distributed version control systems like Git or Mercurial) which nicely complimented some of the research/experimentation that I've been doing.

The review states its goals very clearly: lowest cost-per-repository, with storage used as a secondary consideration. Everyone will have their own needs to rank providers across.

For me, I'm interested in a mix between features and pricing, especially using it on a consulting basis with lots of clients, and different kinds of clients (from those that don't use version control at all, to those that have in house developers already).

RepositoryHosting.com is clearly the lowest price-per-repository: it's $6 / month for unlimited repos with a bundled 2GB of storage, plus $1 per additional GB of storage. No "cost per project" means I can generate a project per client / idea / whatever and not have to worry about it. There is bundled ticketing in the form of Trac, and it's likely OK / has evolved since I got sick of it when we used it at Bryght -- I'm not giving points in this review for PM tools in any case. The WebDAV shares is a very cool feature, especially for integrating clients, designers, and other folks into the mix that will find it hard to adopt the version control system directly.

On the features side of things, my pick goes to Beanstalk. It starts with a free plan so you can check it out right away with 1 private repo. The first paid plan is $15 per month, and I'm fine with their 10 repository limit, but I'm always annoyed at limited user counts. Regardless, it is a super clean interface that people will find very easy to use and it integrates with a ton of different tools (Twitter, Basecamp, Harvest, etc.). But the main reason it is a choice that I'm going to be using more and more is that it offers direct FTP / SFTP deployment. I think this makes it a perfect tool for design-centric shops -- they can continue to use FTP-based hosting services and workflows, while starting to adopt best practices version control.

Bottom line: Unfuddle is a great all in one solution and one that I recommend to clients over and over again if they have no PM or development management tools in place, but for just repo hosting, you should consider RepositoryHosting.com and Beanstalk.