Hofmockel.org

Release management with version control Managing the code on your servers is a very important part of the release process. Over the years we've tried many different ways and have found the below process as a tried and true starting point, but here we'll focus on revision control (Subversion or Git) and the use of tags in each for any given project. Since many of our clients are large traffic websites and need multiple web heads, we also have some standard practices and scripts that we like to use on our projects to help keep the web heads synchronized. So let's take a look.

Blocks vs. Context vs. Panels

As with many facets of Drupal, and coding in general, there are multiple ways to accomplish the same task. A good exmple of this was with the recent additions to the Lullabot team. The expanded team brought together three skilled developers and an amazing designer each with their own methods of site building. On one side we have Jerad Bitner and myself, who for the past few years have been building sites exclusively with Panels module. On the other side we have James Sansbury and Jared Ponchot who also build beautiful sites using the more recent Context module.

Our first collaboration was the redesign of Lullabot.com, since this project was initially designed and scoped by James and Jared, the decision to use Context module was already in place. I was in no rush to learn Context, when I knew the same result could be achieved with Panels. Lucky for me James and Jared are both excellent resources for answering questions and giving great examples. Now that the project is complete I have a better understanding of Context module. This article is intended to identify the similarities, differences, pros and cons of using each module to build a Drupal website.

Angie Byron wrote a nice article on Drupal.org that explains something about how to form_alter CCK fields. At the very end it says:

No, you didn't read that wrong. Sometimes you need to set both ['value']['#value'] and ['#value']['value']. And other times you need to change the field value in $form_state['values']. It seems to be that one controls the value displayed on the form, and the other affects the value sent to the database. You need both to avoid NULL values and "Value is required for field blah blah blah" errors.

If anyone can shed some light on what the heck is going on here, that would be awesome. ;P

In other words, register for the Portland workshops now!

That's right, our upcoming Drupal Module Development Deep Dive workshops week in Washington, DC is now officially sold out. Congratulations to those of you who were fortunate enough to register in time. To those who didn't register, better luck next time (insert sad trombone sound here).

But wait! Speaking of next time, we're continuing our new Deep Dive tradition with another full week of workshops in Portland, OR from August 2nd through 6th. This Drupal Theming Deep Dive week will focus on all things Drupal Theming. We guarantee to turn you into a Drupal theming expert in one week! If you register by this Friday, July 9th you'll save mucho bucks with the Early Bird Discount, so go check it out and register today.

Drupal Theming Deep Dive week in Portland, OR

Our weekend sale is almost over

If you're not on our mailing list or following us on Twitter, you might have missed the Independence Day weekend sale going on in our store. Today (Monday) is the last day to get 25% off all Lullabot Drupal and jQuery tutorial DVDs and high-definition video downloads.

Spend some time this summer turning yourself into a Drupal superhero!

It just keeps getting better. Seriously.

So… Drush. Are you using it yet? If not get drushing!—or whatever you call it. If you're not familiar with it, Drush is a command line interface for Drupal sites. It's the bees knees, if you ask me. You can use it to enable/disable modules, run update.php, get a SQL dump of your site, and all sorts of other magically delicious things.
The problem is, it just keeps getting better. I almost can't keep up with it! The recent release of Drush 3 includes all sorts of goodies, and every day I seem to find more and more. I'm going to take a quick look at a few of them that I'm most excited about.

Drush remote capabilities

One of the awesome new features in Drush 3 is the ability to run Drush commands on a remote server. So, I can run commands on a remote site without having to manually connect to that server. In order for this to work, you'll need to have Drush on the server as well as your local machine, and you probably want them to be the same version as well. You'll also need to be able to ssh to the server using key authentication. Check this out:

drush username@myserver.com/path/to/drupal#mysite.com status

One of the things Drupal core does not do well at all is provide an easy way to switch on a WYSIWYG editor. There is no editor out of the box and setting it up requires some custom configuration of several Drupal core settings, installing and configuring several contributed modules, and also installing one or more external libraries, like the TinyMCE library. The Lullabot book, Using Drupal (O'Reilly), devotes a whole section to describing one way to configure a WYSIWYG editor.

The Problems

It's complicated because there are lots of inter-related parts:

1. You need to set up one or more roles that can edit content.
2. You need to create and configure 'Input formats' to create at least one format that allows users to add the html and css needed to create rich text content.
3. You need to select and install a WYSIWYG editor: install the editor, download an appropriate javascript library and move it to the right location (which varies depending on which editor you are using), and then configure the editor to use the library.

And all of that gets you only to the point where you can edit text. If you want to allow users to upload images and insert them into their text, you also need to identify which of several possible methods of image handling you want to use, and install and configure the modules needed to manage that.

Sam's the man!

Sam Boyer (sdboyer) has been a long time inspiration to and awesome resource for me when it comes to Git. It's really no wonder that he was chosen as the Git Migration Lead by the Drupal Association.

Here are some of his plans and where you can help participate:

Last month Angie and I drove up to Petaluma, CA and did an interview with Leo Laporte at the TWiT Cottage. We talked about DrupalCon, the upcoming release of Drupal 7, and did a general check in with Leo about Drupal. We forgot to post this here on Lullabot.com right after it was posted, so in case you missed it, here's the video of the interview!

An audio version and other options are available at http://twit.tv/specials17

Just a reminder that the early-bird pricing for July's Deep Dive Development Week in Washington, DC ends next Friday, June 11th. If you'd like to become a Drupal development genius and you'd like to save some money, be sure to sign up soon. Seats are limited and they're going fast.

Here's the synopsis:

The week of July 12th, Lullabot will be offering two back-to-back Drupal development workshops at the Hotel Palomar, in Washington, DC. The workshops are Basic Drupal Module Development (July 12 & 13) and Advanced Drupal Development (July 14, 15, 16). You can sign up for each workshop individually, or sign up for the whole week, save some money, and become a Drupal development super-hero!

Lullabot Drupal experts Angie "Webchick" Byron and Jeff "Eaton" Eaton will be spending an entire week in beautiful Washington DC teaching attendees how to customize and extend Drupal and bend it to their will! Spend an entire week with Lullabot and get an in-depth understanding of Drupal programming.

The tools we use and the reasons we use them.

Almost a year ago now Development Seed had an article on some of the tools they were developing in order to address a very real, very important problem—that of the whole development to staging to live development process. Up until these tools were available, this process consisted of an archaic—and quite frankly, pain in the butt—method of either duplicating the clicks and changes you made through the Drupal UI in your various environments, or putting all of your changes that needed to be made to the database into update hooks that did very specialized queries, set variables, installed or uninstalled modules etc, etc. This came with a heavy price tag of testing your migration path over and over, resetting your database, and testing again. Oops! Small mistake there... change the code, reset the database, run it again, wash, rinse and repeat. These tools attempt to change all that and now that they're maturing, they've become a godsend for site builders and developers everywhere. Here is the workflow and process we are using at Lullabot and some of the finer points we've picked up along the way.

Almost 3 years ago, I wrote a article called How Drupal Will Save The World. In that post, I talked about the importance of usability to Drupal. I also outlined how a more easy-to-use version of Drupal could lead to a shift in not only the way that websites are made, but it would also change the people who make them. Easier website creation is the key to changing the demographic of Drupal site builders.

I certainly wasn't the only person to notice that Drupal needed to be easier to use. And over the past 3 years, the Drupal community has made many efforts to improve usability and user interface. Probably the most noticeable user interface changes will be coming with the Drupal 7 release in the next few months.

Building a business

My article didn't really have any action items so much as it laid out several possibilities and some "what if" scenarios. Liza, Matt, and I had been mulling over this idea of improving Drupal usability for a while, unsure how to pursue it, when Liza began talking to Ed Sussman. At the time, Ed was president of Mansueto Digital running FastCompany.com and Inc.com. He came from a more traditional business and entrepreneurial background and he had ideas about how this could be turned into a business – a situation which could provide the financial foundation to keep the concept moving forward and allow a dedicated team really streamline the user experience.

Thus began a 2-year project with lots of user research, usability experimentation, interface wrangling, and basically rethinking Drupal's functionality and user interface from the ground up. Ed eventually left Mansueto and became the CEO of our new company. Lullabot became a co-owner of the company and invested many hours of development, guidance, and experimentation. We also brought in Karen McGrane, a prominent user experience and interaction designer whose resume includes the current New York Times redesign.

Most people don't want Drupal. They just want what Drupal does.

The result of all of this work is Buzzr, a complete reconcepting of Drupal. Buzzr is a user interface which sits on top of Drupal, allowing for easy one-click configuration, drag-and-drop layout changes, and simplified options. It's all Drupal underneath. We've just got a different interface. We flatten Drupal's learning curve by shielding site administrators and end users from Drupal's cockpit-like administrative screens.

Buzzr doesn't do everything that Drupal does, but it can do most things which most users want – and by building on top of Drupal, we've got lots of room for expansion with so many modules and functionality we can incorporate in the future.

Try it out

In case you missed the announcement, Buzzr went into public beta a few weeks ago at DrupalCon. You can visit Buzzr.com and start creating websites today. There is also a white labeled Enterprise Edition so that universities, corporate institutions, and other organizations can create their own customized web systems and give their users the ability to quickly create and edit their own Drupal sites using Buzzr's simplified user interface and hosting solutions.

A Lullabot Business Case Study

Last month, I had the opportunity to speak at DrupalCon San Francisco. I had a great time speaking. I did a case study of Lullabot itself, in which I talked some about how the company is structured, some of our core beliefs, and about my own business ideas and strategies. (You can watch the slides and hear the audio here, or access the slides here.)

I'm a huge advocate of giving things away (creating value), and then using smart business models to capture some of that value. Part of what I talked about during this session was how to determine one's value as a Drupal shop. When I first came to Lullabot (about a month after Matt and Jeff founded the company), the company was swamped with work requests. Raising our rates was a great filtering mechanism for us, and also helped "buy" the free time that our awesome team members need to do things like write books, co-maintain an entire release of Drupal, and maintain four billion modules. But for us, it was a total guessing game. We basically raised our rates until we reached the point where we started meeting some pricing resistance. We've done careful tweaking of our rates over time, but we're at a point (after 4 1/2 years in business) that we're confident in our rates and very confident in the value that we provide for those rates.

Assembling a high performance site that uses PressFlow, ApacheSolr, and other external files

Most of us have heard of Drush by this time. It's a cool command line tool to make it easier to set up and update Drupal. A really handy addition to Drush is Drush Make, a tool that makes it easy to identify all the files needed to create a new Drupal site and automatically retrieve and download them. Most Drupal sites have at least a few files that come from non-Drupal locations -- like javascript or flash libraries that need to be downloaded separately and moved to some specific location within your Drupal installation. Drush Make makes it easy to pull these files together.

All the examples I had seen for Drush Make used Drupal core, but I recently wanted to create a new site using PressFlow, an alternative to the regular Drupal core code that has lots of performance enhancements. The PressFlow files are not hosted on Drupal.org, they need to be retrieved from the PressFlow site. The site will also be using ApacheSolr and jQuery UI, both of which require grabbing code from external locations. I wanted to create a system to pull these files together automatically using Drush Make, but it took a bit of digging to figure out how to do it.

For the Subversion impaired

So you've probably already heard that Drupal.org is turning to Git for it's version control system (VCS) needs, but you may be wondering, "Well, how do I get into the practice of using Git?". And if, like most developers, you are using Subversion for most of your projects, then I have a really great suggestion on how to start making this transition.

Varnish is an excellent high-performance, HTTP accelerator. The technical term for Varnish is a "reverse proxy cache", meaning that it handles the requests when you visit a website acting as a cached layer of content on top of Apache. This means that after a page has been requested once from the web server, Varnish keeps a copy of that file in an ultra-fast storage so that the next time that page is requested, it returns it immediately instead of starting up Apache, PHP, MySQL, and any other technologies your web site may be built upon. If Varnish doesn't have a copy of the file or page being requested, it will request the page from the normal web server.

This article explains step-by-step instructions on how to get started with Varnish on a local Mac OS X sandbox. I personally set it up with the MAMP package, but because it doesn't make any difference what web server you use, you can use these instructions to set up Varnish in front of the built-in Mac OS X Apache or anything else you may have installed from MacPorts or compiled from source.

If you're not familiar with setting up a web server on Mac OS X, you'll need to get that working first. I'd recommend the Lullabot videocast on Installing a local web server on Mac OS X.

Today is the last day of our Week-of-DrupalCon 25%-off sale. All Drupal tutorial videos and everything in the Lullabot Store is 25%-off this week. And this week ends today!

To be the first to know about upcoming Lullabot sales as well as coupons, news, and updates, be sure to get on the Lullabot Mailing List and/or follow us on Twitter.

I just finished my talk on moving from CCK in D6 to Fields in D7, and promised to post my slides, which are full of references to the relevant issues. There is no place to do so on the DrupalCon session, so I'm posting them here.

For reference, the session description was:

Fields in Core will be exciting and powerful, but we still have some work ahead of us. Now it's time to figure out how to get there from where we are now. Hundreds of developers need to update their CCK-related modules, and thousands of administrators will need to update their data. Plus not everything about CCK made it into core. Which modules and functionality were left behind, and why?

Karen Stevenson, one of the CCK maintainers and part of the team that got this code into core, will talk about the upgrade path and the 'left-behinds', and what those of us who have been using CCK in Drupal 6 will need to do to adjust to Fields in Core in Drupal 7.

We previously mentioned that we're planning a party at DrupalCon San Francisco. Here are the details!

The super-awesome Lullabot party will be held at:

Jillian's
101 4th St.
San Francisco, CA
(right next to the Moscone Center)

On Monday, April 19th
Start Time: 7:00 PM
End Time: 10 (or so)

Google Map Directions

We hope to see you there!

Here's an updated version of the DrupalCon schedule based upon the version currently posted on their website. Some of the session times may still change, but this should be a good way to take a quick look at which sessions are happening concurrently.

There's also the source excel file in case you want to tweak it any way.

If you see any errors, feel free to leave them in the comments.