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.
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.
We use the context module for Drupal in every site we build. It's a great way to do things like create separate "sections" of a site, with different behaviors and layouts based on an arbitrary set of "conditions" or triggers. For example, we may want Blog posts to have a different layout than other parts of a site.
A version control system is essential to keep track of code changes, and provide a repeatable, reversible process for applying those changes to development, staging and production websites. At DTEK, we used Subversion (svn) for years, but recently made the change to Git. I won't get too deep into the reasons why, but the main win for us is the fast and simple branching; our workflow seems to be less "work" and more "flow" now that we're using git. ;-)
A Drupal web site we're building requires a "slidepicker" for the front page. Maybe there's a better name for this feature, but it's a variant on the ubiquitous "slider" or "rotator" effect that allows a lot of content to be prominently displayed without horribly cluttering the page. Standing on the shoulders of giants, this feature was simple and fun to build, so we thought we'd share our technique.
I have recently begun using MAMP for local [drupal] site development on my iMac (running OS X 10.6). The free version works great right out of the "box", but it only supports a single site. Admittedly, I could just pony up the $60 for MAMP Pro and get name-based virtual hosts, among other niceties -- but, it's just apache, right? Which means it's just a text file somewhere...