Drupal developers [hopefully] find themselves writing "field formatters" fairly often. These pieces of code add ways to display the data stored in fields, so having an arsenal of formatters can come in handy.
Making formatters is often straightforward, but some of the work gets repetitive and tedious. The snippet below should allow you to at least get up to speed more quickly, if not make the "settings summary" a worry of the past.
Every year our team heads out to DrupalCon together. It’s always a great time to get out of the office and experience new things as a team. We get to travel, explore a new city, and learn the latest happenings with the Drupal web platform.
This year it was our project manager, Andrea’s, first time attending DrupalCon and she really loved it.
“I had a great time at DrupalCon Austin taking in the conference, meeting new people in the Drupal community, and learning more about managing Drupal projects.
It's kind of a bummer: Views exposed filters use GET parameters to pass arguments, but Views conditional filters use core path arguments.
Sometimes you want to use the exposed filter values for different displays, or swipe GET parameters from non-View functionality.
On the Galaxie site, we have a View with exposed filters where you can toggle by a particular machinery category. Each page that comes up then has a block that describes the category you're viewing.
At Commercial Progression, our development team tends not to use bulky modules like Panels or Display Suite without a reason that justifies the overhead. Those decisions (which we revisit frequently) lead to a particular site workflow, which we refine over time.
One Drupal design pattern I used on a recent site led to: