Development

My old Drupal core development workflow revolved around CVS. Anytime I'd want to work on a new feature I'd do a CVS checkout of Drupal core and start working on the new feature. If I, or someone else, was working on 2 features that overlapped in code I would have to deal with massive conflict resolving or just have to wait until the other feature was committed or abandoned. Oh, and I had to be connected to the Internet to grab a new CVS checkout. That all changed when I switched to Bazaar for my core development work.

Some Of What I Can Do With Bazaar

Bazaar, a distributed version control system, let's me do a lot of things that simply can't be done with CVS or SVN. Here's a short and incomplete list:

• I don't need to be connected to the Internet to create new feature branches.
• Merges are much better making them useful. That makes branches cheap, easy, and useful.
• I can make branches of other feature branches allowing me to layer patches and issues.
• Did I mention merges are better. This means a lot less conflicts to deal with.

How do you react when your pet project is criticized? How about when a project you use and love is criticized? When it's the same criticism you've heard over and over you and are tired of hearing it? That's happened yesterday to the Drupal Views project when a tweet sent out of frustration turned into a swarm of tweets, IRC conversations, and back room talk.

Every so often someone points to the markup generated by the Drupal Views modules and calls it ugly. This seems come up every so often in the forums, issue queues, blog posts, and on twitter. Most of the time this is where the conversation turns a bit ugly. Since this conversation has been had many times the people who are involved are a bit tired of explaining what's going on to someone new and to many Views is their baby and it was just called ugly. So, let me take a shot at explaining why Views markup is the way it is, why that's good for some, and what you can do about it if you don't like it.

The Deal With Views Markup

The markup from Views has to be very flexible out of the box. It's going to be used by a lot of people to do a lot of different things. So, the markup provides spans, divs, and classes for almost every case you'd want to style. If you are someone who lives in CSS and loves classes and separation of everything it's there for you. There is a certain group of designers that want this and they have been vocal and are, for the most part, happy with the markup.

Can't Make Everyone Happy

As the saying goes, you can't make everyone happy all the time. Having lots of spans, divs, classes and other forms of markup is directly opposed to small concise markup others love. You can't have both out of the box and what Views picked is actually easier for new people to pick up.

In Drupal to alter the output you need to know how the theming system works and how to override the default markup. Since Views provides lots of markup many people can learn to style the output without needing to know how to alter the markup output of views. It saves them from a layer of complexity.

Having Markup Your Way

If you are a markup purist and want to change the markup output by Views it's there for you to change. Views uses the templating system provided by Drupal and has a display plugin system of it's own. With the templating system you can override all of the markup provided by Views and replace it with your own. It's almost as simple as copying the Views template files into your theme and altering or replacing them.

The Drupal Design Camp in Boston this past weekend was fantastic. Having the event at the MIT Stata Center, a building that looks like it's right our of a Dr. Seuss book, was a perfect place for a design event. With well over 150 people, loads of fantastic sessions, and ideas for improving the tools and community designers and themers have the camp was a roaring success.

Photo by Jeff Eaton. Everyone is pointing at Morten.

Most of the shared Drupal themes aren't very good and there aren't very many commercial ones. That's what a study shared by Jay Batson pointed out. Jay went on to propose some steps we could take to court better design in the Drupal community. While he made some important points, there is one important point that was overlooked. The issue of crediting designers for their work.

Mark Boulton and Leisa Reichelt have suggest drupal provide inline editing in the interface. This is a fantastic idea and one I would love to see in drupal. But, (I hate this part) inline editing in drupal is a difficult feature to add. So, before everyone wonders whey we don't offer it or why it's going to take some work let's look at why this is hard.

Have you ever submitted a url to a site just to have the site tell you it was invalid when you knew it wasn't. That happened to be recently and happened on one of my drupal sites. Drupal told me a flickr url containing an @ symbol was invalid. When I looked deeper into the issue I found the URL really was valid. When I looked to see what other software was doing I found many cases where there was no validation or what was present failed for many types of valid urls.

Most of the development to drupal core happens through a patch review process. Even bigger changes, like the new database system, where development happens elsewhere, eventually go through a patch review process. This process can be intimidating to anyone who hasn't done it before or doesn't feel like they have a high enough skill level to contribute anything to core. In reality, anyone can review patches. Even individuals who can't write software at all.

When we updated the Geeks and God podcast to drupal 6 we migrated away from using the audio module and are now using CCK and filefield to manage our audio. This has enabled us to use modules like filefield podcaster to generate our feeds and have views generate different feeds for our different file types.

The audio module has been good to us but we didn't need most of its added functionality and some things, like ID3 tag management, had turned into a little bit of a nuisance.

A number of other people have wanted to make the same conversion and I have been asking me how to do it more than a few times. So, I wrote up a tutorial called "Drupal: Converting From Audio Module To Filefield Module".

Last week, Bob and I launched a new look Geeks and God podcast and community site. When we had first launched the site two years ago, under drupal 4.7, it was a basic site where page nodes were our podcast and we used an outside software like feeder and feedburner to generate our feeds. Since then a community has grown around the podcast, the technology has come a long way, and the dynamic around the site has changed. To embrace this we rebuilt the site, added new features, and re-constructed our data model (we have a data model for the first time).

In Episode 102 of the podcast we walk through many of the technical changes, the modules we used, how and why we built what we built and more.