Building Drupal sites, I often want to create a placeholder for a small bit of content -- and track that placeholder in code (e.g. with Context, Panels, Features, etc) -- while still allowing the actual content to be edited freely by site editors. If I just create the block via the UI, I'm not tracking the "configuration" of the block (as opposed to its "content") in our version control system, but if I implement a "normal" block in my module, the Block body is not available for editing.
Recently installing Ubuntu on a new machine for the first time in a while, I was reminded of some obnoxious and potentially dangerous behavior regarding SSH agent (as articulated by my friend dkg a few years ago). In particular, Gnome Keyring is started by default, has some behavior that I don't like, and is difficult to disable in favor of the SSH agent provided by Open SSH that I prefer. The Gnome Keyring behavior I don't like is:
Over the last year we've been working with the Department of Forestry at the University of Washington to help them improve their Climate Change Database, an application to measure the sensitivity of Pacific Northwest species and habitats to climate change. Recently we finished our work by migrating the application over to the UW's partners at The Nature Conservancy.
As of August 1, the new business address and phone number for DTEK will be as follows:
606 20th Ave
Seattle, WA 98122
206 219 9163
After more than a decade of work and many evolutions along the way, DTEK is scaling back operations and is not accepting new clients. The company will remain as a freelance web development vehicle for me, primarily for the purpose of honoring existing contracts and maintenance retainers.
Upgrading a complex Drupal site can be a tricky proposition. This post will explore using the Migrate module to bring users and their role assignments from a D6 site to a fresh new D7 site. We created similar migration classes for taxonomy terms, nodes, and comments, which will not be covered (see the 'Resources' section below, or leave a comment if you need some direction). This is a followup to my last post about upgrading from Drupal 6 to Drupal 7, and presents a potential alternative approach.
This was my third Drupalcon, after San Francisco in 2010 and Chicago last year. Despite my slow and snowy drive from Durango, the weather in Denver was beautiful - and much warmer than either San Francisco or Chicago. The Denver Drupal community deserves a huge congratulations and thank you - this event was outstanding, and I am thoroughly impressed! The venue was great, the sponsors and parties were super fun, the food was probably as good as we'll get when feeding 3,000+ people, and as icing on the cake, the wireless worked great for me!
The Pratt Center for Community Development in New York City is one of DTEK's oldest and best clients, and has been running on Drupal 6 for two and a half years (Andy migrated them from a custom php site in 2009). This will be a pretty tech-heavy post about how we planned and executed the major upgrade of their site from Drupal 6 to Drupal 7. The major question in any Drupal upgrade is whether to follow the core "upgrade" path - as defined in UPGRADE.txt - or to re-build from scratch and then do a data migration.