develOOp another fine develOOpment

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

Kathleen Murtagh (aka ceardach) talks about the deployment process at Going On and how they're using the features module to export functionality into code. Murtagh was working on a series of database scripts to handle some of the deployment process, but this has been deprecated in favor of the features module. Other modules mentioned are Organic Groups, Spaces, Devel and Masquerade.

read more

We're working on a project with too much non-uniform legacy HTML to migrate it all into Drupal. Some of it we're handling by migrating certain data into nodes and dumping the entire HTML content into the node body so it can be easily indexed by Solr for search and the titles can be included in other views listings.

read more

I'm currently developing some Drupal 7 instructional videos for lynda.com. The company likes to offer "exercise files" for their courses so folks can jump in in the middle. In other words, someone could start at Chapter 5 by loading the Chapter 5 exercise file, which would make the site appear as though all the exercises from Chapters 1-4 had already been completed. A course would have at least a half-dozen such files (if one per section), and possibly as many as 70 (if one per video, as is preferred).

This has proven very difficult in Drupal. In Drupal Essential Training (2008) we included a .sql file at every step, but that didn't put assets in their proper directories. We included graphics wherever they first appeared, but that meant a user would have to go through all previous chapters to find the assets and load them up. That also didn't address the issue of modules and themes. It's been a support nightmare.

An ideal exercise file would:

read more

So you're building a Drupal Feature! Woohoo! Okay, so…. What to include? What to leave out? How to structure the thing so it doesn't conflict with other Features? How to avoid known issues? Where to start?

When, in theory at least, you can make an entire site into one big Feature, these questions become extremely important.

If you're using Features simply to help facilitate your own site-building workflows, this may be something you can pretty much ignore. When dealing with Features you've made for yourself, you may remember your thinking, you may follow your own logic, you may be using Features as a blobby deployment system for all kinds of stuff glommed together. Whatever works. It's all good.

But that approach won't fly with publicly shared Features. In fact, it won't work too well for teams either, probably. Without best practices, clearly laid out and understood by all, Features can trend towards amorphous nightmares. Features might conflict with each other, undoing each other. Improperly utilized, Features can easily become a nightmare that slows you down, undoes your hard work, and leaves you ready to scream and throw your computer out the window.

The KIT Specification clearly lays out requirements for building clean, discrete Features.

read more

So you're building a Drupal Feature! Woohoo! Okay, so…. What to include? What to leave out? How to structure the thing so it doesn't conflict with other Features? How to avoid known issues? Where to start?

When, in theory at least, you can make an entire site into one big Feature, these questions become extremely important.

If you're using Features simply to help facilitate your own site-building workflows, this may be something you can pretty much ignore. When dealing with Features you've made for yourself, you may remember your thinking, you may follow your own logic, you may be using Features as a blobby deployment system for all kinds of stuff glommed together. Whatever works. It's all good.

But that approach won't fly with publicly shared Features. In fact, it won't work too well for teams either, probably. Without best practices, clearly laid out and understood by all, Features can trend towards amorphous nightmares. Features might conflict with each other, undoing each other. Improperly utilized, Features can easily become a nightmare that slows you down, undoes your hard work, and leaves you ready to scream and throw your computer out the window.

The KIT Specification clearly lays out requirements for building clean, discrete Features.

read more

Sabina Rose
May 22, 2010
2:28 AM
8 lbs, 2 oz

Politika is an effort to make an amazing looking and rich-featured theme for Drupal 7 and 6. It will be designed for the community, and in part by the community… though it will not be designed by democracy; to maintain a coherent and high quality design that adheres to web and accessibility standards we will have to be a republic. But the good type of republic, that listens to the people!

1. Art Direction
2. Graphic/UX design
3. Drupal theming
4. Documentation

1. Type of website for which this theme will be designed (blog /portal/ media/ multimedia/etc..)
2. General directions for the style, atmosphere and design stream (e.g. minimal/clean vs web2.0 vs glossy)
3. Recommendations of modules and content types to be supported and designed

June/July 2010: Collecting information

July 2010: Being on vacation resisting the urge to make design mock-ups

August 2010: Providing some design mock-ups for the community to choose from

read more

I finally got around to making a "real" feature rather than just playing around with the functionality.

I had left a comment a while back on Peter Rukavina's post 'How to run a silent auction using Drupal' about how this would be perfect as a feature. So, I installed a new site, grabbed the necessary modules, and turned Peter's description into a silent_auction feature.

The code is available from my (also brand new) Silent Auction Github repo.

This was a very easy process. I'm familiar with Drupal site building, so I point and clicked my way through the content type and manage fields screens as the main component of the project. Peter did a very good job of documenting the steps he took, so it was easy to do.

I then added his custom code to the silent_auction.module file to override comment displays. I didn't quite complete the "amount raised" block - my buggy custom block code needs some help, Github collaborators welcome :P

read more

Over the weekend we launched a Feature server at http://downloads.pingv.com.

Currently it has but one simple Feature: an initial release of "Photo Essay," for posting images inline in the text of an essay. We hope some people may find it useful. Or informative. Or inspiring to go make their own Features.

We see a bright future for Features. As strategists and designers, we embrace systems and practices that increase the speed and efficiency of development. Features are a great way for people to be able to mix and match components to build sites to suit their needs, without having to install and configure everything by hand, and without needing to embrace a whole website strategy inherent in a full-blown Distribution.

This is a new area of growth and rapid change in the Drupal community. It's very exciting.

So far it seems like most of the Features that people have released are designed to serve use cases more on the advanced, complicated side — with a goodly proportion of those targeted specifically for installation in Open Atrium, which in many ways has been the proof of concept for Features in the first place.

read more

Over the weekend we launched a Feature server at http://downloads.pingv.com.

Currently it has but one simple Feature: an initial release of "Photo Essay," for posting images inline in the text of an essay. We hope some people may find it useful. Or informative. Or inspiring to go make their own Features.

We see a bright future for Features. As strategists and designers, we embrace systems and practices that increase the speed and efficiency of development. Features are a great way for people to be able to mix and match components to build sites to suit their needs, without having to install and configure everything by hand, and without needing to embrace a whole website strategy inherent in a full-blown Distribution.

This is a new area of growth and rapid change in the Drupal community. It's very exciting.

So far it seems like most of the Features that people have released are designed to serve use cases more on the advanced, complicated side — with a goodly proportion of those targeted specifically for installation in Open Atrium, which in many ways has been the proof of concept for Features in the first place.

read more

read more

For the past couple of months I've had my hands on an Apple iPad and one of the first things I was interested in trying out was how effectively I could manage my Drupal sites with the device. Since I didn't want to jump to hasty conclusions about how good or bad the experience is I've waited all this time to write about it. In general I'll say that it's not a bad experience. The larger screen makes managing your site much more realistic than on the iPhone which I think is nearly an impossible task because of the small screen size. With that said you won't want to sound much time engaging in hard core site building on the iPad either.

read more

read more

So, amongst all the discussion of import methods lately I just wanted to flag another possible approach - creating a CiviCRM hook module for the Drupal migrate module

There are a bunch of great blogs out there on how to use the table wizard module with the migrate module to import data from various mysql tables or views into Drupal nodes / users / taxonomies / content types - for example:

http://www.lullabot.com/articles/drupal-data-imports-migrate-and-table-wizard

The migrate module has a bunch of hooks to allow you to use it for other forms of migrations. I rattled up the module / code pasted at the end of this blog in a couple of hours as a proof of content for using this approach to CiviCRM imports. The code I threw together just offers up civicrm_contact table fields but I think there must be some clever ways to use existing import tools rather than this rudimentary approach.

read more

I was trolling around the Internet today looking for benchmarks and I actually had a little trouble finding something current. Dries has one comparing D6 on PHP4 vs D6 on PHP5 but that was clearly ages ago.

read more

Twice today I've had to deal with writing a SQL query that needed data in a CCK field. The naive approach is to just look at the table and field names and plug them into your query:
<?php
$result = db_query("SELECT COUNT(*) AS count FROM {node} n
INNER JOIN {term_node} tn ON n.vid = tn.vid
INNER JOIN {content_type_date} ctd ON n.vid = ctd.vid
WHERE tn.tid = 25 AND ctd.field_date_value > NOW() AND n.changed > %d", $newtime);
?>
Often this will work just fine but since CCK can dynamically alter the database schema (when you add a field to a second content type or change the number of values) the query may break.

read more

Jerad Bitner, Jared Ponchot, James Sansbury, and Jeff Robbins talk about the redesign, relaunch, and reworking of lullabot.com and talk about the development techniques used -- in particular the use of the Features and Context modules.

read more