Planet Drupal

Cool Content - How to gain popularity through Drupal modules

What's a site worth if you can't ambiguously tell authors how terrible their articles are by rating them on a scale of 1 to 5 chili peppers? How can we segregate against nodes by only allowing the popular nodes to sit at the cool nodes table? Well lucky for us we're going back to high school in this blog post as I introduce you to a few cool Drupal modules that show us how to get organic results for popular content.


Fivestar is one of the more basic, but useful rating modules that adds “rating stars” to content. Users rate the node based on the number of stars you made available, then you can view the average rating of the node to see how popular it is. Simple right? Fivestar is based on Voting API, is officially supported in Acquia Drupal, integrates with Views, and is easily the quickest way to add ratings to nodes.

Want to extend Fivestar? Check out Fivestar Recommender. Want your own custom Fivestar widgets? Drupal Ace can show you how in their Custom Fivestar Graphics tutorial.


Rate is pretty similar to Fivestar in the voting aspect, but it also allows for thumbs up/down, emotion ratings (funny, mad, angry), etc. It’s like Fivestar and Vote Up/Down all in one, plus a bit more. Rate also has some interesting features, such as Rate Expiration, which disallows voting after a set period of time (for that one guy who wants to down vote an article... 3 years after it was posted). Rate doesn’t allow users to cancel their vote, whereas Fivestar does. Some will bicker back and forth about which one is better, but we’ll leave that to the drama nerds and their never ending debate between Star Wars and Star Trek... Which by the way, a Star Destroyer could take on the Enterprise any day. Just ask these guys.

Want to add some visualizations? Mix it up and integrate with the Google Chart API to show off those sexy bar charts. I can hear the ladies running already.

User Points

If you want to add a bit of narcissism to your site, look no further than User Points. Okay I kid, healthy competition between users might be a better phrase. User Points allows users to gain or lose points by performing different actions on your site. This may be writing a product review or commenting on a node. With this module, the users are fighting for popularity instead of your content. User Points ties into Services, Rules, and Views which makes it even more site builder friendly.

If you’d like to extend User Points, check out this list of contrib modules to add even more functionality.


If this list of modules were your high school homecoming court, then it’s time to meet your King (or Queen). We’ve met the runner-ups, but Radioactivity steals the show. This module will give you the most organic results for content based on popularity. Radioactivity provides more of a hotness meter. When an entity is getting attention (either by views or actions defined by rules), it will become hotter by an increasing energy that you set, while those that are not receiving attention are cooling down. Pretty cool, huh... er, I mean hot? You get the point.

So why the name Radioactivity? The cool down rates are based on the concept of half life, or the amount of time it takes for the quantity of something to reach half of the original value. Using Radioactivity, you create a decay profile that sets the cool down rate for the entities it is assigned. Want to know the current trending articles on your site? Set the half life to 3 hours and the granularity to 15 minutes (which is the interval of time to update the energy), and watch as the popular articles float to the top while the not-so-hots sink to the bottom in real-time. Have an ecommerce site? Integrate Radioactivity with Commerce using Commerce Product Popularity.

Of course there are a number of settings you can use in the module, such as using memcache for storing energy values, so it’d be nice if you had some direction. Though on the project page there’s a few links for tutorials or documentation, I think that Teemu Merikoski of Wunderkraut has an elegant writeup for Radioactivity.

Know of any interesting modules that help showcase popular content on your site? Let us know in the comments below.

Thoughts from BADCamp: A Shift From Drupal Services To Drupal Products

While visiting BADCamp in Berkeley, CA last week, I sat in on several discussions about productizing Drupal. Jeff Walpole, CEO of Phase II opened the discussion with a presentation on various business and product models the Drupal community has embraced.

Jeff’s experience in growing a successful services company has been that of hard work, long hours and hiring top Drupal talent to fulfill the requests of his clients. His team has created several Drupal distributions that have awarded Phase II business in the government space, yet the distributions themselves have been expensive and taxing to develop and maintain, and have been difficult to quantify based on sales.

One long-term business model would be a shift to productize Drupal in a way that is sustainable, scalable and maintainable. Creating a diverse and robust ecosystem of complementary products and services that compliment the Drupal platform would benefit the community and could add recurring revenue to a business. While this model looks good on paper there are several challenges that need to be overcome.

The first challenge that arises is licensing and selling. To dispel the myth of GPL licensing, we can in fact sell Drupal core, Drupal modules, Drupal distributions, etc. The question then becomes, how can we sell something that is freely distributed? The answer to that question is complex and open for debate.

Another question asked was, even if we do sell Drupal modules and/or distributions, how do we keep others who have purchased our product from giving it away to others for free? The answer is that we cannot…unless we tie it to proprietary APIs or services.

APIs, plug-ins and 3rd party services that support Drupal seem to be the way many forward thinking businesses are approaching the product challenge. By creating these valuable APIs and/or products we can create value to the community and design a product model that broadens our revenue stream.

So what great products can we create that will both be hugely beneficial to the Drupal community and provide monetary value to the business that owns, promotes and supports it? Whoever figures that out will be a true rockstar in the Drupal community.

Converting Views List Into Responsive Stacked Columns

If you have ever worked with views and columns in Drupal, you may have had the unfortunate and rather difficult task of getting the columns to render out just the way you really want them to. After some research, I believe I've found a workable approach.

The most common approach is probably cutting the row widths in half and then floating them left. This gives the "illusion" that they are actually in "columns". This works great, if you want the view's row results to read left to right. However, I recently came upon the need to have the view rows to stack on top of each other and then overflow into the second column.

Many of you might be thinking, "Why didn't he just use a Grid style plugin in Views? That is, after all, what it's there for!"

Answer: Responsiveness!

Grids render in table markup. Anyone that has ever tried theming a table to be responsive knows it's a lot of work to override default table positioning behaviors.

There had to be a better approach in getting these columns to actually function the way I needed them. After doing a quick Google search, I came across the the Views Column Class module. Great! This looked very promising! I started to mess around with it and quickly realized that it added classes in a custom view style. Yes, this could work. However, it's still the same technique that we use for creating left to right "faux columns" - relying on classes to float left or right. What I really needed was to actually alter the markup that was generated. I needed to separate the rows into columns that have their own



markup. This would allow for easier manipulation and styling of the actual columns. I started searching some more.

I finally came across this wonderful blog by Amanda Luker: Flowing a list view into two columns. Granted it's a little over a year old, but it definitely got me on the right path! The technique is rather solid, but I'm not really a fan of using preg_replace(). For performance reasons, it's better to generate the correct markup in the first place. No need to generate markup only to replace it later. This is Drupal after all!

Not only that, I also needed to accomplish the following:

  1. Easier way to manage which views get processed and converted into columns
  2. Standardized view classing for the columns (including zebra striping and first/last classes). This is very useful for theming purposes.
  3. Dynamic Columns. Have the ability to produce any number of columns, more than just two.

In the end, I felt just doing some rewriting was in order. In the end, this approach helps with all the previously mentioned tasks at hand. Below are the source code files (in Gist) needed to start preprocessing Views Columns:

  1. template.php - Contains the preprocess hook needed for your theme. I figured preprocessing an unformatted list would probably be the easiest.
  2. views-view-unformatted.tpl.php - The template file needed for your theme.
  3. views-columns.less & views-columns.css - These are supplemental and are really just base styling for creating evenly width 2 and 3 columns for tablet sizes and up.

I have tried to document these files fairly well, however if you find that additional documentation is needed please feel free to comment below or fork the Gists!

Image courtesy of: Flowing a list view into two columns by Amanda Luker.

Drupal Hosting by Pantheon: The Good, the Bad and the really, really Frustrating.

Frustration has motivated me to write a post about this. These are largely a lot of issues I have with Pantheon. I will address the good things first.

The good bits (Some of which you may already know)

Innovative: I feel Pantheon is doing a great thing. They're helping Drupal developers simplify their workflow. They've created a service that stands above most other hosting services that currently exist. Additionally, Pantheon exudes the culture of listening to the Drupal community and continually trying to improve their product.

User Interface: For the most part, the user interface is pretty good. You're able to find things that you need without too much searching. It's not perfect and it could be improved.

Multi-tenet deployment is cheap: Being able to deploy a multi-tenet deployment structure is very easy and takes little time and effort. It's just a couple clicks away. You upload your database and then upload your files folder and after you get your favorite warm morning beverage you have a new Drupal installation created.

Upstream updates: Being able to run updates for Drupal core is awesome. A single click allows you to update code quickly without having to click through the interface. Although, drush is equally sufficient for this task.

Quick backup: With one click you're able to execute a complete backup. The backup is also conveniently compressed for quick download.

The bad bits

Pulling in changes: Moving from dev/staging/live requires clicking. I may be in the minority but I really enjoy using git purely through the command line interface. Having to pull in changes in your testing environment by clicking can get old quickly.

Drush / SSH-less access: While some innovative folks in the contributed module space have created a Drupal project for drush access, it still limits you from what you can do. I understand the limitations exist due to large concerns of security. Without Drupal or ssh access, it can often be a burden for Drupal developers. I would much prefer to have the ability to sync databases and files a command line interface with Drupal. I know Pantheon does a great job of creating user interfaces to replace this but being able to `drush cc all` is superior in my opinion.

Working the Pantheon way: Using Pantheon, you're tied to a specific workflow. This includes exporting the database, downloading it from the browser and then importing it into your machine. This is OK the first 10 times. After a while it gets quite old. I would much rather use `drush sql-sync` for this.

New Apollo Interface: The new Apollo interface has too many tabs and fancy dropdowns. Changing the environment now requires clicking twice. Click the dropdown, then pick your environment, then pick the tab on the left side. Someone went a little crazy with Twitter bootstrap. I would rather see a longer page. The tabs/dropdowns often abstract where and what you need. Also, you have to re-learn another new workflow for it to work. This is a slight curveball.

503 Errors: This issue was of the most problematic. On one of our website setups, it produces an unhelpful 503 error every time you would visit the features page or to clear cache. This became instantly an impediment on our team's productivity. We've posted a ticket; however, the ticket process has been rather slow. Different techs have come in, passed the issue and escalated it each time; but we have yet to have a resolution. (We're on day 7 of this problem.) Being able to call and wait for an hour or two and getting it resolved then would be more efficient of my time; especially when something like this is becoming an impediment to our project.

In the end it's up to you

Overall, it all depends on the workflow and tastes of the Drupal developer. Pick and choose what works for you. For some people, Pantheon is the right service / tool for their job. For me, I would much rather prefer more granularity and control. I really desire for Pantheon to succeed. Pantheon is fulfilling a need that exists in the Drupal community. Hopefully, they'll continue to improve their product and I'll give them another shot later on. At the moment, it's not what I'm looking for.

Do you agree, disagree or have comments? Please let us know below.

Photo from Sybren A. Stüvel's photostream.

Don't Be a Noob, Top 5 Most Common Drupal Beginner Mistakes

We here at LevelTen work with Drupal every day so as you can imagine we've seen a few horror stories unfold where clients have hired an inexperienced developer to build their site for them. Here's a list of the top 5 most common mistakes that inexperienced developers make, and a few tips on how you can avoid them.

5. No Man is an Island

Drupal has a pretty steep learning curve, and can be downright frustrating at times. If you're new to Drupal and don't have an account on then the world can be a pretty lonely place. There are literally thousands of people all over the world willing and ready to help you learn your new craft, and the more you contribute back to the community the more likely they will want to help you. Hours of tearing your hair out can be saved simply by doing a Google search or checking the issue queues for module bugs and patches.


  • Create an account at and get involved as much as possible. Part of Drupal’s strength is having users who give back to the community.
  • Attend Drupal Meetups and Camps to find out what’s new, and what the Drupal rockstars are using.

4. Reinventing the Wheel

So you've taken the time to learn all about Drupal’s hook system and some of the basic APIs that it uses and you're ready to dive in head first, right? Wrong. As an already experienced developer, your knee-jerk reaction to any challenge may be to jump directly into the code and start doing what you do best, but in doing so you will quickly eat up any budget allocated to the project. There's no sense reinventing the wheel if someone else has already done most of the legwork. Modules take little time to install and configure, and they're FREE.


  • Before you jump into building a module from scratch, always research what’s already out there to prevent extra work in the beginning – you’re likely to get a head start with an existing module.
  • Use Google to search “How-To” tutorials. A 5 minute video can save you hours of fumbling around admin screens trying to figure it out on your own.
  • Set up a sandbox, an environment you can break and test modules on, before using them on a real website.

3. PHP in the WYSIWYG

This is really more of a pet peeve than anything else, but every time I see PHP entered in from the Drupal interface I throw up in my mouth a little bit. PHP belongs on the backend, not in the database. WYSIWYGs are fine for basic (and I mean, basic) content formatting; however, inserting anything more advanced than late-1990's HTML will cause it to be wiped out as soon as the WYSIWYG attempts to format the code. Since you probably don’t want all your hard work to disappear, taking the extra time to do it the right way might be appropriate.


  • Check out the Block API, hook_menu(), and hook_theme().
  • Create a module specifically for the site that will handle any one-off customizations. This can also be used to create pages and blocks that require programmatic code that you would otherwise enter into the WYSIWYG.
  • As a last resort, disable the WYSIWYG and restrict access to users if possible.

2. Killing Kittens

Someone who is unfamiliar with Drupal, or the use of content management systems in general, may think that it is perfectly OK to play around with the code in Drupal’s core. Among the Drupal community, we refer to this as hacking core, or "killing kittens". While it may address an immediate need and be a little bit faster than writing a custom module, or creating a theme override, don't be tempted. You'll be opening yourself up to some serious issues. Drupal releases regular updates for core, and developers are constantly updating modules, which you won't be able to install because they will overwrite any changes you have made. Now try to imagine finding out that the high-profile website you've been working on has been hijacked and is at the mercy of the hacker because you weren't able to install the updates needed to fix those security holes after you edited core.


  • For God's sake… think about the kittens!

1. The Rube Goldberg Website

One of the easiest and worst traps for a budding Drupal developer to fall into is that of code/configuration fragmentation. If the backend of your site looks like a Rube Goldberg machine and requires a Ph.D. or some bizarre wizardry to make edits to then you’re probably doing something wrong. One of the brilliant features of Drupal is its highly modular construction. In the right hands this construction can be extremely powerful; however, in the case of an inexperienced developer it lends its self to some very complex, and often unnecessary, configuration setups. One rule of thumb is that if it takes several hours to track down all of the steps required to make a simple change, then try doing it a different way.


  • If you think you might forget how you did something, then you probably will.
  • Your theme should be used strictly for display purposes only, leave the functional components to the modules.
  • You should be able to toggle modules on and off without causing any major breakage.

Have you experienced any of these horror stories or challenges?

Are there any other tips you'd offer to beginner Drupal developers?

Share your comments below.

Improving Menu Views in Drupal 7 to Create Mega Menus More Efficiently

After a little over 9 months and with an impressive 1290 sites reporting they use it, Menu Views has undergone a little nip and tuck! Today, I have finally released Menu Views 2.0-rc1 in hopes to squash the ever so annoying bugs and wonderful feature requests that were made! This module has been an invaluable tool in the mega-menu creation process. It has solved a problem for many people: how to insert a view into the Drupal menu system.

Many Drupal sites I've seen through out the years (those that have complex mega-menus) left me perplexed at how to accomplish this task. I could never really imagine it happening effectively, unless it was rendered using views. After being able to finally see how some of these sites actually accomplished this great feat, I was also a little baffled at the shear complexity of making it happen.

Often times, the theme is the unsuspecting and unfortunate victim. Being hacked, sliced and injected with arbitrary code to succeed in rendering the desired result. Some prefer to do it this way and to them I say "be my guest". However, when a more dynamic approach is needed, it is far better to utilize the awesome power of Drupal. Which begs me to reiterate what the purpose of a CMS is for: letting the system actually manage the content (hmm novel idea).

Menu Overview Form

Eureka! Let Drupal's own menu system and administrative user interface handle this complex problem! When I first released Menu Views (1.x) that is what it solved: inserting a view into the menu. However, it also introduced quite a few other problems that were unforeseen and rather complicated to fix. Namely these involved other contributed modules and the biggest native one: breadcrumbs!

Over the past few months, I really started digging into the complexity that is the menu system in Drupal. Trying to figure out what exactly I could do to help simplify how the replacement of links were intercepted and rendered. After pouring over the core menu module and several contributed modules, I began noticing several commonalities in the best approach: theme_menu_link().

In Menu Views-1.x I was intercepting theme_link() instead. In hindsight, I can't believe how incredibly stupid that was! So essentially, the old method intercepted every link on the site with the off chance it might be a menu link that had Menu Views configuration in the link's options array. Whoa... major performance hit and a big no-no! For this reason alone, that is why I decided to do a full version bump on Menu Views. Part of this decision was to consider existing sites and how they may have already compensated for view were popping up everywhere. An additional deciding factor involved refactoring the entire administrative user interface experience.

Menu Item TypeIn Menu Views (1.x), there seemed to be a lot of confusion around "attaching" a view and optionally hiding the link using <view> in the link path. I thought about this for a while. Ultimately I decided that the best way to solve this would to separate the view form from the link form and give the administrator the option to choose what type of menu item this should be. In this way, menu views can more accurately determine when to intercept the menu item and render either the link or a view.

There are now a couple options to better manage what the breadcrumb link actually outputs as well. Along with rendering a title outside of the view if desired. Both of which can use tokens! No longer are we left with stuff extraneous markup in the view's header. Last but not least, one feat of UI marvel: node add/edit forms can control menu views and you're no longer limited to just the menu overview form!

Menu View Form

Per some user requests, I have also set up a demonstration site so you can firebug to your heart's content: I push blocks on the left and right to show that it integrates well with Menu Block, Nice Menus and Superfish.

Overall, I think Menu View's new face lift will allow this module to reach a new level of maturity and stability that has been greatly needed. Thank you all for your wonderful suggestions in making this module a reality and truly a joy to code!

Stay tuned for next week: Theming Menu Views in Drupal 7

The Top 13 Reasons to Come to Dallas Drupal Days 2012 THIS WEEKEND

We are less than 24 hours away from our fourth annual Dallas Drupal Days conference, with a Drupal Business Summit on Friday and DrupalCamp on Saturday. If you need more motivation to be here ..

    1. Hear Josh Koenig, fresh from interviewing Dries at the DrupalCon Munich keynote, talk about "The Drupal Destiny". With a name like that, it's got to be good.
    2. Learn how McKessen, 15th on the Fortune 500, built their Patient Portal using nothing but Drupal and tongue depressors.
    3. Find out 10 ways your Drupal site can get hacked. It just might be getting hacked RIGHT NOW!
    4. Visit the Results Oriented Social Media Summit going on at the same time at the same venue and totally included in your ticket. If you are into that squishy social stuff... (ed. Heeey! I like the squishy social stuff! I'll be there!)
    5. Get educated on using OAuth in Drupal, Dancing, and in Life.
    6. Improve your CSS skills by learning LESS / SASS / COMPASS / WOPR / WoW and CPR.
    7. Become knowledgable about Drupal 8, 9 and 10. * did you know Drupal 10 will be developed entirely using Higgs Bosons?
    8. Absorb information on mobile applications strategies for Drupal. The slides for this session will be projected onto a 3x4 inch screen.
    9. Be taught how to build Drupal modules. Please bring transcripts from your PhD in Computer Science for admission. Not really. An MS is fine.
    10. Listen to the smooth, smooth sounds of Travis Tidwell teaching you how to make money in Drupal and Open Source.
    11. Be force knowledge choked by Darth Vader himself with his Guide to Drupal SEO and Galactic Domination. Yes, that Darth Vader.
    12. Talk about how great Dallas Drupal Days was Saturday night at the after party at the Fox & Hound, with free drinks and food.
    13. Join us for a post-Camp mountain bike ride on Sunday. Tom McCracken will demonstrate his perfected endo techniques.


With dozens more sessions, if you haven't registered already, you better soon- time is running out.

Adding custom icon sets to the social media module

There are dozens of cool social media icon sets. Many designers want to create a custom set of icons to match their theme. The social media module was built with an icon set manager API.

The social media module for Drupal includes a default icon set called LevelTen Glossy. It also has built in support for a half dozen other free icon sets. Just download them, put them in the correct folder, and presto they are ready to use.

But what if you want to add your own icon set? Here is how to do it.

Adding a custom icon set social media

The file contains the API. You can use that code as a starting point. You will want to implement the API in your own custom module such as example.module. The first step is to implement hook_socialmedia_iconset_info();. In your module you will want to add a function like this:

function example_socialmedia_iconset_info() {
$icons['myicons'] = array(
'name' => 'My Icons', // name of your icon set
'publisher' => 'Me', // name of publisher
'publisher url' => '', // url to publisher's site
'styles' => array( // different variants of icons available
'16x16' => '16x16',
'32x32' => '32x32',
'48x48' => '48x48',
'path callback' => 'example_icon_path_myicons, // callback for icon urls
return $icons;

This works very much like hook_menu();. It just tells the system about a new icon set and provides essential information.

The second element you will need is your path callback function. This needs to match the ‘path callback’ element in hook_socialmedia_iconset_info(). This function is to return the path where the icon can be found.

function example_icon_path_myicons($platform = 'twitter', $style = NULL) {
$style = isset($style) ? $style : '32x32';
$pt = array(
'googleplus' => 'google_plus',
$path = drupal_get_path('module', 'libraries') . 'socialmedia/icons/myicons/' . $style . '/' . ((isset($pt[$platform]))? $pt[$platform] : $platform) . '.png';
return $path;

When you create your icon set, you will want to follow the standard naming convention which can be found in the socialmedia_icon_platforms() function. If you do have an icon name that does follow the convention, you can use the $pt array to define exceptions. For example, in the above code, the Google+ icon is named google_plus.png, not the standard of googleplus.png. So an exception was created in the $pt array.

image by webtreats

If you aren't using Entity API to create nodes, you are doing it wrong

For many years now I've written code to programmatically create nodes. I've done it for dozens of clients starting with Drupal 5. It has always looked the same, been very procedural and felt very wrong. Recently I started playing around with turning this chore into object oriented and started writing a module.

Well yet again it turns out there is already a module for that. The entity module. Not only did it do (almost) everything that I was trying to make my module do but it does far far more. In fact, it has totally revolutionized the way I write integration code.

Have you ever done something like this?

$node = node_load(1);
$node->field_reference[LANGUAGE_NONE][0]['nid'] = '463';
$node->field_text[LANGUAGE_NONE][0]['value'] = 'Some Value';

If you have, don't ever do it again.

Many of you know that the Entity module is great for defining new entity types using the Entity API but it has another really great API within it. That is turning all the core entities into REAL objects, not just pretend objects. By this I mean that it adds a lot of methods to the objects as well as just properties.

The example above would be:

$node = new EntityDrupalWrapper('node', 1);
$node->field_reference[0]->set(463); // Note that this is a multi value field.
$node->field_text->set('Some Value'); // Note that this is a single value field.

Or if you want to get extra fancy, you can do the following:


class Node extends EntityDrupalWrapper {
public function __construct($data = NULL, $info = array()) {
parent::__construct('node', $data, $info);


$node = new Node(1);
$node->field_reference[0]->set(463); // Note that this is a multi value field.
$node->field_text->set('Some Value'); // Note that this is a single value field.

It makes me so excited to be able to interact with core entities in an entirely object oriented fashion. The Entity API module with the EntityDrupalWrapper will wrap most of the core drupal entities with plenty of useful helper methods.

It has revolutionized the way that I write integration code and hopefully it will yours as well. So next time you need to programmatically create nodes, check out the Entity API and the EntityDrupalWrapper.

Photo courtesy of

Start showing some Skinr 2 in Drupal 7!

Many of you might be familiar with the module Skinr ( It gained a lot of support back in Drupal 6 by providing an easier, albeit somewhat verbose, way of dynamically configuring how elements on your site are styled. When I first started using Skinr, it worked as advertised; however, it ultimately left me with a bitter taste in my mouth. I felt like I was constantly trying to navigate an endless maze while blind-folded. There were options upon options and fieldsets within fieldsets. It had almost everything but the kitchen sink in it. I never really have been one who enjoys feeling like I’m just wasting my time. So I eventually scrapped this module as being a potential long term candidate for managing customizable styling. Apparently I wasn’t the only one who had these concerns either. Then the 2.x branch was born. I only started using the 2.x branch because it was the only one available for Drupal 7. They had completely scrapped the old interface and did an amazing amount of work to make Skinr easily maintainable. You can view a list of changes here: So if any of you are like me, you probably were thinking: “Skinr, in Drupal 7? I don’t want to make this any more confusing than it has to be!” Well fear not! You can learn how to start Skinr-ing in just 7 easy steps! Let us know if you're using this module and leave us a comment below! Photo By: abbsworth