Recently FeedAPI 1.7beta2 was released, and this new release has Drush support. Drush, in a nutshell, lets you handle your Drupal instance with standard unix command line tools (DRUpal SHell), and with Drush support now in FeedAPI, you can better control your feeds. In this post, I'll introduce you to a way to refresh your feeds faster and more efficiently.

This method is only useful when your Drupal site runs on a VPS or a dedicated box, otherwise you cannot really use Drush at all. The script uses multiprocessing and starts refreshing four feeds at once. However, it's not a true parallel since the next four feeds will only start refreshing after all of the four previous feeds are finished. You can also adjust the number of feeds that you'd like to start in a round. The script is basically an infinite loop, but don't worry, it won't eat up all your server resources. If all of your feeds can be refreshed in a short period of time (900 seconds, configurable), the script will wait a bit before it starts from the beginning again.

Imagine a similar solution in pure PHP. It would have to be really hackish because of the lack of parelell/multithreaded constructs in PHP. And needless to say, with this script you don't have to worry about memory limits and timeouts (you can have a separate php conf for the command line environment).

Here is the script:

Yesterday, Eric talked about how feature servers can help organizations manage and update features on different of sites and I pulled together a screencast of an initial proof-of-concept. While we’ve been talking about these ideas in the office for a while, the actual implementation is very new and I was surprised at how quickly it went – in all, the feature server took less than a day to build.

Here’s a look at the feature server with a prepackaged theme (more on that below):

What it does

• Lets you create projects and releases and manage them by hand on a Drupal site.
• Produces an update XML feed compatible with the update module in core.

What it doesn’t do

• Version control integration and automated packaging. The project module does an awesome job of this, and if you’re serious about tying your features into VC it’s what you’ll want to look at.
• Anything with dependency / build management systems (a problem that Adrian Rossouw and others are spearheading in the community).
• Info file based parsing, dependency detection, and display.

The ingredients

Adrian pointed out to me that this very simple version of a feature server could be a feature itself. It turns out he was right – it is largely generic site building with some additional custom components:

It's common for organizations to run 20+ different program websites. The bulk of these program sites need several of the same features like a public blog, a pressroom, and media resources. A few key programs might need a sensitive CCK-based reporting feature that was designed in house.

This screencast by Young, who blogged about the power of decentralized features yesterday, is a first look at how a feature server will let you pull features from multiple sources and get updates for them in both public and potentially secure and private ways. If you're not familiar with the features module, you may want to watch the screencast introducing it before watching this one.

The feature server architecture is incredibly simple because it leverages core Drupal components to their fullest. Believe it or not, the feature server is itself a feature (exportables for node types, CCK fields, Views, etc.) with a few small custom components (e.g. a Views style plugin for generating the update module-compliant XML).

After my previous post introducing Features, people had some very good questions. How can you share features that you’ve built? And how can other users get your features?

We think the answer to these questions is to use a feature server. At its simplest, a feature server is a website where someone can get features and get updates for those features. It could be a private repository for a network of Drupal sites within an organization, or it could be a public facing site from which anyone can download and add features to their own Drupal website.

How fast can you install modules? Drush, the Drupal command line utility, takes what normally is a tedious task and turns it into a delightful experience.

Final Times
Manual Method: 2:38:75
Drush Method: 1:17:57

Module installation is just one of the things Drush can help you with. Learn what else it can do for you on the project page: http://drupal.org/project/drush.

Open Atrium (formally code named 8trees) is an open source intranet package powered by Drupal that’s fast and easy to install and start using, and open source so you can customize it to meet your exact needs. It’s first public release will be in mid July, and all of its code will be hosted on Github as an open beta. To be first in line to access the code, message @open_atrium on twitter.

As a team intranet, Open Atrium lets you coordinate on projects with the people you work with – whether that’s to facilitate programs around the world for an international organization, to organize the communications outreach for an advocacy campaign, or to run out simultaneous projects for a software development company. Out of the box you can create different spaces for different projects, add people to each space, and turn on different tools within each space, including a blog, a wiki, a calendar, a casetracker, and a micro blog.

Here are a few screen shots from our intranet showing some of its features:

Calendar

This weekend CrisisCamp is coming to Washington, DC to advance the conversation around how technology can be best used to improve how we respond to disasters and other humanitarian crises.

Eric, Robert, and Tom will be there from Development Seed and are excited to dive into the conversation, hear how people are using technology in disaster scenarios, find out what works and what doesn’t, and learn what needs still need to be met. We’re particularly interested in learning what information and data first responders still need. Recently, we’ve done a lot of work to make maps and government data more open and accessible, by getting US TIGER data hosted in Amazon’s cloud and road map data from several African countries up on Open Street Map, and we’d love to find out what other information first responders need.

CrisisCamp is set up BarCamp style, and Robert is hoping to lead a session on some of what we’ve been working on, specifically on how to integrate Drupal with open source GIS tools. In this talk, he’ll show some examples of Drupal sites that leverage PostGIS, Mapnik, OpenLayers, GeoRSS, and Amazon Cloud Storage that give distributed teams flexible ways of creating and sharing maps.

If you’ll be at CrisisCamp, be sure to say hi to Eric, Robert, and Tom, and if not, you can follow the action on Twitter at #crisiscamp.

Adrian Rossouw is celebrating his love of the launch of Drush 2.0 by giving out a few I <3 Drush t-shirts to the people who can best communicate just how much they share Drush love. He just posted about this today in the Aegir group.

If you’re a Drush head, make a screencast or write a blog post explaining how Drush has made your life easier and your coding faster. Once you’ve posted it, tweet about it with the hashtag #drushrush. Adrian and a few friends will select the top three productions and mail the creators a free t-shirt, so you can look just like him.

You can also buy the shirt over here.

Today roughly six months after creating the Drush 2 branch, the Drush project released Drush 2.0.

You can buy a Drush t-shirt and help grow the cult here. (thanks Alex Barth!)

Drush, which stands for the “DRUpal SHell”, is a command line interface to Drupal that bills itself as a “swiss army knife” for Drupal developers. The rule of thumb is that if there’s a commonly run task that involves many clicks on a Drupal site, there’s probably a Drush command for it. Drush is also one of the best kept secrets in the Drupal community. Due to its nature it won’t end up in any Drupal.org usage lists, but there is no denying the improvement in workflow that people experience when starting to use it.

Because Drush 2.0 is no longer a module, you only have to install one copy of Drush on the server, and then you can use Drush on any Drupal 5, Drupal 6, and Drupal 7 sites you may have.

To run a Drush command just change into the Drupal root directory or the Drupal site directory that you want to run the Drush command on and type in ‘drush command’. You can get a list of Drush commands by typing: drush help.

I’m working out of Development Seed’s main office here in Washington, DC for a few weeks, which gives me the opportunity to show off some of the cool stuff we’ve been working on at the Drupal Meetup tonight at Stetsons. I’ll talk about Aegir, a hosting system that streamlines deploying and upgrading multiple Drupal sites, and show its support of installation profiles and multiple languages.

I’ll also give an exclusive preview of one of the “secret” projects we’ve been working on – Atrium, an intranet package built with Drupal – and will show how Aegir ties into it. In this preview I’ll also show the new admin module for Drupal 6 that Young built for the Atrium release and talk some about the roadmap that we have for doing an open beta release of the package. Much of this has been kept under wraps, but since there are some key people in DC who are working with the Alpha release, we thought it would be fun to share with the group.

Here’s a quick look at Atrium with the admin module at work:

My presentation will build on the Install screencast I made a few weeks ago and explore some of the possibilities of what you can do once you have Aegir installed. To give people a sense of where the project is heading I’ll also discuss the progress that has been made towards porting the user interface to Drupal 6.0 and some of the future plans for the platform. The intended audience is anyone who needs to manage Drupal sites and doesn’t want to be tied down with all the unnecessary manual administration.