Drupal 7: Fancy exposed view filters

A couple of days ago, we were looking to theme a set of Drupal 7 View filters that were also using AJAX to load the new View content. By default, the filters were rendering as a set of radio buttons so by default we were getting HTML that looked like this:

The problem was that given the design mockups we had, styling the filters to match with only CSS was going to be impossible. Writing a jQuery plugin to dynamically replace the filters with custom HTML was pretty straightforward but the tricky part was getting a notification that an AJAX request had completed so that we could reload the filters.

We managed to do this using the Drupal.behaviors Javascript object using code that looks similar to what is below:

Anyway, nothing to crazy but there doesn’t seem to be a ton of documentation about the Drupal.behaviors object.

Congrats: 500pearlstreet.com launched!

Our friend Walt launched 500Pearlstreet.com earlier this week. It’s a blog that will be focused on covering white collar crime in the news as well as exploring other topics related to white collar crime. We’re excited to see where Walt takes the blog and wish him the best of luck!

Technically, 500Pearlstreet.com is running Drupal 7 with a couple of of pretty neat modules:

  • The theme is a standard sub-theme of the excellent Omega responsive theme. The amount of configuration possible through the Omega UI is really impressive and a welcome change from how difficult theming was in Drupal 6.
  • In-context links and images are being automatically powered by Zemanta which is pretty neat.
  • OpenCalais is also running in the background providing semantic tagging capabilities. These aren’t exposed yet but hopefully will become useful when there is more content.

Anyway, it should be a good read so drop it into your readers!

Fixing blank CCK Location fields in Views

Recently, we inherited a Drupal 6 site via a client of ours and ran into a pretty irritating bug with the Location module.

The site had been configured to allow users to create profiles using Node Profile along with the Location to allow users to input their street addresses.

Anyway, the issue was that when we created a View that included Location fields the fields were always rendering as blank even when we confirmed there was data in the database. A bit of poking around lead to this issue.

It turns out that due to an optimization in CCK or Views that the tables that have the data for the location fields are not getting JOIN’ed in when the view is executed. Unfortunately, the patch provided on the issue doesn’t work on the latest 3.x release of the Location module.

The fix that worked for us is #14 (copied below)

* Preprocess hook for location().
function yourtheme_preprocess_location(&$variables) {
  if (!isset($variables['location']['name']) && isset($variables['location']['lid'])) {
    $variables['location'] = array_merge($variables['location'], location_load_location($variables['location']['lid']));

Basically, you’ll need to add the above snippet to a template.php file in your theme and change the name to reflect the theme you’re using. What this function does is basically pre-process the location fields to pull in the data so that the View will work properly.

Anyway, enough blogging it’s football time.

Scaling HerCampus.com

Over the past month we’ve been working with Her Campus (HerCampus.com) to help them with issues they were having. When we started talking with Her Campus, we learned that they had different types of issues ranging from some Drupal based ones to actual server level problems. They were having some trouble keeping up to traffic demands, and if a traffic spike occurred their current infrastructure wasn’t sufficient.

After looking at their setup, we noted quite a few areas in which we could improve performance. The old setup was a fairly standard setup, a frontend server using Apache to handle HTTP requests and then a second server which was their MySQL database server. The servers were a 4 gig and 8 gig server respectively.

It was clear Apache was adding unneeded overhead, and wasn’t the best solution for them. We revamped their setup significantly. We switched them to Nginx + PHP-FPM. We immediately saw great improvement on from this change alone. However we wanted to get them to a single server, and to be able to handle traffic spikes with a single server.

We ended up doing the following:

  • Switch from Apache -> Nginx+PHP-FPM
  • Update all MyISAM tables to INNODB tables, and upgrade their MySQL to 5.1
  • Tune MySQL settings to fit their requirements
  • Update several tables adding indexes, reducing query time from in one case 34 seconds to 0.02 seconds.
  • Add the Boost Module to their setup
  • Update several of the view queries to be better written, added caching to each query.
  • Use ImageCache and sub-domains to load assets

After these updates we were able to move them from their two servers (8 gig and 4 gig) to a single server(4 gig). We have also reduced load times significantly. Their server loads dropped from 4-5 on average to 0.25. Recently they had an article on the Huffington Post and didn’t have any problems handling the 4x traffic spike they saw. At points we were seeing according to ChartBeat over 600 people on the site at once. The single server handled this without problems.

The updated infrastructure will give them a savings of about 75% from their previous setup. It also gives the users on the site a much faster and reliable experience.

We look forward to helping Her Campus with their continuing expansion of their site and user base!