Just going to DrupalCon to watch is awe inspiring. The amount of people there, all sharing one common goal: to learn more and grow the power of Drupal, thereby empowering themselves... it's all really inspiring stuff. There's more than a few reasons I keep coming back.
We are as excited as everyone about heading to Portland in a few short weeks. I'm convinced it is going to be one of the most significant DrupalCons yet.
However, I was a bit disappointed when I learned that so many of our favorite tools have no session coverage at all. These aren't some niche modules, either. These modules have been used in almost all of our projects in the last few years.
Time and time again the debate about "what is content" and "what is configuration" comes up. I think not often enough we talk about it in words but not in the intentions of what you are building. This article is just about content, because everything else is just code.
First of all, what is "Content", really? It recently has become crystal clear to me:
Content is something that can (and should) be safely edited in real-time on your live website or application.
We are Drupal architects and engineers that help organizations that are adopting Drupal. We believe that a dev shop transitioning to Drupal needs more than technical training, but also help with development and management strategy, site and data architecture, and server infrastructure.
As Drupal's popularity grows by leaps and bounds, web companies of all kinds are forced to adopt it. Sales teams find it incredibly easy to sell Drupal, because of all the things it offers, and all "for free". The problem is, Drupal is more than a piece of software. It is also more than the community. It is an entire culture
With 2012 over, were now approaching a full year of development of what started out as a pet project of mine: DevShop.
Development environments are complicated. There are a lot of moving parts. This is why services such as Pantheon and Acquia Hosting are so popular.
I've always used Aegir, since about version 0.3, because I loved that it removed the complexity of creating databases and users, secure passwords, settings.php files, apache vhosts, and file permissions. This frees you up to focus on the site at hand. However I noticed over the years, that despite the things aegir takes off your plate, maintaining all of the sites, files, and users that a even a small development team requires is a lot of work!
I will never manually create a database again. As long as I work in Drupal, every database I create or user I grant permissions to is managed by the Aegir hosting system.
I will never manually set up the code on my server. As long as I work in Drupal, every new site will come from a Git repository, and will be installed onto my server via DevShop and Aegir, through the web browser.
Today I went through setting up another Atrium for another client. As I start going through and turning on the same things I always turn on for any, I think about how we might create our own enhanced atrium profile... Then I step back and realize, first I should at least document what changes I always make!
So here it is!
Our Top 5 Enhancements for OpenAtrium
Well, we finally had enough of continually building custom solutions to a perennial problem, so we built a module for that!
I've had the chance to use a little-known function twice in the last few weeks: views_get_view_result().
This little gem does exactly what its name implies: it gets the result of a view in raw data form. The other day I used this to get a list of our top taxonomy terms for a special select list for coaches.integrativenutrition.com.