Contributing Code for Prairie Initiative - the technical side

You are viewing a wiki page. You are welcome to join the group and then edit it. Be bold!

1. Develop small features locally

To really work on features I'd say you need a local copy of d.o. Only the relevant sections would be enough, but as they are hard to cut out we go with a complete copy.

To get a local copy of

Apply for bazaar pull access for the d.o. live repo. This way you can always pull the latest d.o. code from that repo.
The process is described in detail here:

You can work on stuff in this local site.

The stuff we create will be mostly views, content types, maybe blocks and organic groups. So probably there won't be too many code changes on d.o. that affect

2. Upload your code to the sandbox project

Leisa has created a sandbox project: (URL will be inserted here)
Wen can use it for an issue tracker and to collaborate on the code.
Once you have a chunk finished, try to export content types, views, css files and post it up to .
If you are good with Features module, you can also pack it as a Feature, which should be easiest to extend on and continue work.

3. Our shared Dev Server

When something appears promising, we will upload it to our Development Server, so everyone can see it.

We have a dev environment at
This does not keep in sync with the current d.o. code, it is a one-time checkout that has to be kept up to date manually.
This can be accessed by ssh. Also we can use drush on there. Apply here to get access.

This page explains the Dev Server in Detail:

Basically we could work on there with several people. But as we have no version control on there, things might get shaky with overwriting each others changes.
Once you got ssh access to, got to /var/www/dev/

This is the root of our dev website. In the root you find a file "comment". In here you find the password for user/1 to log into
Fun fact: user name is Dries, since he was and is user/1 on d.o. So you log in with Dries/pw from comment file


I look forward to seeing code

drumm's picture

I look forward to seeing code contributions, but am worried about this process. Along with a few others, I've been working to provide high-quality dev sites on our server, The whole section of the site is starting to get filled up with some excellent content,, especially thanks to webchick. New documentation should be updated there, rather than duplicated here.

We used local development for the redesign project, and I was a big believer in it. However, it is just plain cumbersome. You have to be a sysadmin to get the basic services working; Linux does decently and other platforms do have some installers that help. And the data, even after reduced, takes a long time to move around.

Using the central server has worked well for a couple projects, and The have taken awhile since there has been debate about what the functionality should be, and affect a few modules for deployment. They have been the exclusive way people have worked on I now use the exclusively, my local dev environment just got too outdated and hard to update with new data. These projects have had multiple collaborators from the start. The sites being public has been a real asset.

As far as I know, we have not had any real issues with people stepping on each other's changes. If a site gets too noisy, we can provision a new one. It is always good to break up work into smaller, deployable chunks, and get them done. Architechting the redesign really taught me that monolithic projects are not fun.

The system does have some rough edges, but is always improving. I just added support for bakery last week so we can do some real testing when improving that. We are planning some larger moves as well.

Prairie Initiative

Group organizers

Group categories

Prairie tags

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds:

Hot content this week