Features is a module that solves a Drupal problem: configuration and content are both stored in the database.
Drupal DeploymentHow do you test in dev, then stage then production?
Make the same configuration changes once in each environment?
No, that's boring and error-prone!
Copy the database or specific tables from one to the other?
No, that's also error-prone and if you mess up you might be losing content.
Pfff. Just do everything in production - it's faster that way.
Just - no.
Our solutionUsing the Features module to export Drupal configuration to code. The code can then be deployed to stage and production using subversion and Features will manage changing the database settings to match.
Make a change in the UI
Put that change into a feature
Use subversion to deploy the feature to stage and test it out
Use subversion to deploy the feature to production
Commit the feature code to subversion
We used redmine for tracking bugs and work that was not yet done.
Our workflow started with documenting work in redmine tickets. When code was committed with the changes (using features) we could reference the ticket and see it in Redmine's UI.
We structured CCP's content to make it easier to maintain automatically. We were already on board with Drupal, but we decided to re-build the site using Drupal 7.
Existing Drupal site
The existing Drupal 6 site had a page title and HTML from the previous (static) website pasted into the body.
Paste in a new event here
And watch out for:
Did you paste from Word or an email message? Make sure the font is the same as the rest of the page.
Are you using bold and italics the same way for each event?
Right amount of whitespace?
Don't touch this heading
Existing Drupal 6 site
The existing content needed manual changes all the time, and the process was error prone. Updates for the events page went something like this.
Current events appear here, sorted by date
When events are over, they move automatically to the Past Events section.
The content manager enters the event data one time including a date. Events automatically change their display when they're over.
Artist content type
A content manager can now enter data about an artist one time, and it can be displayed in an image list, a table on another page and potentially even on another website.
Image credits on the old website
Content managers had to copy-paste or re-enter credit information each time an image was used on the site. Lack of structure meant that they could not be easily styled consistently.
Artist name (linked to full artist record)
Image file (automatically sized for different contexts)
Consistent credits on the new site
The content manager now enters metadata about the image and the display is controlled automatically resulting in a much more consistent style.
On the old Drupal site, the homepage was in PHP code input format. Content managers didn't have control over it.
In the new site, content managers can define what's most important within the content structure. We also added a random element on the homepage to keep content fresh even when staff were not available to select content.
Maintaining a form
In the old site, the form for requesting rights and reproductions was difficult to use and change.
Maintaining a form
In the new site, Webform module provides a WYSIWYG UI for managing the redesigned forms.