How many times do you find yourself building the same bit of functionality on Drupal sites for various clients? Whether it be a photo gallery, multi-user blog, or slideshow, as Drupal site builders, we often find ourselves re-inventing the wheel. Personally, I’ve been asked to build slideshows on many client (and volunteer) sites that I’m involved with. Over the years, I’ve developed a recipe for a powerful and flexible slideshow that often exceeds the needs of all but the most particular clients. I recently added the ability for the slideshow to be responsive, and now seems to be a good time to share what I’ve done. At the end of this post, I’ve provided the slideshow as a Features that you can implement on your sites.

So, what makes a full-featured slideshow? Here’s my take on what’s essential:

• The ability for any slide to be linked to any URL.
• The ability for site admins to rearrange the order of the slides.
• The ability for site admins to pre-load future slides.
• The ability to tweak the settings of the slideshow data.
• The ability to theme the slides to have HTML titles, descriptions, and attribution information appear as desired.
• The ability for the slideshow to render properly across a wide-range of devices.

Let’s take a closer look at each of these features and their implementation details.

The ability for any slide to be linked to any URL

A common method for creating a slideshow is to simply add a "slideshow image" field to a node type, then filter on that field in the slideshow view. This method has obvious disadvantages - the main one being that slideshow slides can then only be linked to nodes. In a full-featured slideshow, we want the ability for the slideshow slide to be linked to any URL - either internal or external to the current site. This is accomplished by creating a separate "slideshow slide" content type with title, description, and source/attribution fields to describe the slide. Then, with the addition of a URL field (via the Link module) we can also specify where the slide leads to when clicked. The handy Field Redirection module handles the automatic redirection to the URL specified. This custom content type then allows the site administration to create slides that can direct the user to anywhere on (or off) the site.
 

The ability for site admins to rearrange the order of the slides

Understandably, site administrators often want to be able to control the order of the slides as they’re displayed to their users. I used to utilize the excellent Nodequeue module for this, but I’ve recently switched over to the slightly easier-to-use Draggable Views module. This method allows me to create a block that I can place on the Administrative Dashboard that allows the site administration to quickly see all of the current slides, as well as re-order them as often as they’d like to.

The ability for site admins to pre-load future slides

While not a breakthrough feature by any stretch of the imagination, most site administrators often request the ability to pre-load slides that they’re planning on publishing in the future. Since we’re utilizing a custom content type, site administrators can easily use Drupal core’s "published" flag to control this. By creating an "unpublished slides" view block for the Administrative Dashboard, site administrators can quickly see all unpublished slides. By leveraging the Administrative Dashboard, we can give site administrators a complete overview of their slideshow slides.

The ability to tweak the settings of the slideshow data

It is common practice when creating slideshows in Drupal to use one of the many Views display plugin modules. My module of choice is the Views Slideshow module combined with the Flexslider library module (more on this later.) Views Slideshow is a rock-star module in the Drupal community, having well over 120,000 reported installs. By integrating with Views, the site administrator has complete control over which fields are displayed along with the slideshow image. I often include fields like the title, description, and source/attribution information for the image.

The ability to theme the slides to have HTML titles, descriptions, and attribution information appear as desired

Once the desired data is present on each slide, custom CSS can then be applied to the slideshow to overlay the data on the slideshow image, or have it appear virtually anywhere on the page, transitioning in-sync with the slideshow. Your site’s custom CSS must take into account the responsive nature of the slideshow and adapt gracefully. As an example, just 41 lines of CSS were used to style the title, description, and source field as displayed below. The CSS used is attached to the bottom of this post.

The ability for the slideshow to render properly across a wide-range of device

Finally, with the addition of the Flexslider library module, we add responsive hotness to the slideshow. The Flexslider library allows the slideshow to stretch or shrink to fit the width available to it, making it a responsible part of any responsive theme.

Test Drive

Rather than providing step-by-step instructions to recreate this type of full-featured slideshow, I’ve decided to share it by exporting it as a feature. You’ll need a number of modules in addition to the DrupalEasy Slideshow feature download from Drupal.org, but once you have them, you should just be able to go to admin/structure/features and click to enable the DruaplEasy Slideshow. Here’s a list of the modules you’ll need:

• Features
• Strongarm
• Draggable Views
• Field Redirection 
• Flex Slider - be sure to also install the Flexslider jQuery plugin in your sites/all/libraries directory according to Flexslider’s installation instructions.
• Libraries
• Link
• Views
• Views Slideshow
• Entity API
• Chaos Tools

If you're familiar with Drush make, feel free to utilze the .make file I've attached below and save yourself a bunch of time.

What's missing?

Are there any options missing from this slideshow that you consider part of full-featured slideshows that you build? If so, let me know in the comments and I’ll consider adding them to the feature.

It never fails - regardless of the skill level of the Drupal workshop that I'm teaching on any given day, the topic of Drush always sneaks its way into the conversation. Normally, it's because I have to quickly download a module to demonstrate something that has come up in class. Rather than navigating to the module's project page, I just quickly jump to the command line and do a "drush dl whatever" and hope that no one notices the witchcraft I just invoked - this inevitably results in the nerdiest student in the class perking up and wanting to know what the magic is that they just saw...

Ever since Arto Bendiken (Arto on drupal.org) made the first commits to the Drush project back in 2006, it was clear that this was a tool for hardcore Drupalers. Over time, as it has become easier to install and extend, more and more people have discovered it as a versital and time-saving tool. No longer limited to the nerdiest of us, Drush is rapidly finding a home in most Drupalists' toolboxes.

It was just a matter of time before presentations (shameless self-promotion), documentation, and screencasts started appearing on the Planet to spread the word and help increase its adoption. Now (finally), we have a printed book as well.

Packt Publishing has had hits and misses when it comes to their plethora of Drupal books, so I was curious to check out Drush User's Guide, published 4 months ago - especially considering the author is an active member of the Drupal community and the reviewers are two of the co-maintainers of the Drush project. So far, so good.

Juan Pablo Novillo Requena (I can't wait to hear Andrew try to pronounce his name on the podcast), juampy on Drupal.org, despite being a member of the Drupal community for less than three years, has an impressive lists of Drupal contributions and accomplishments under his belt. Jonathan Araña Cruz (jonhattan on drupal.org) and Greg Anderson (greg.1.anderson on drupal.org), two of the Drush project maintainers (with both having commits to the project in the last week) were the reviewers for the book. Before I got to page one of the book, I was already really looking forward to it based on their involvement alone.

But, proving that nothing is so perfect that it can't be complained about, before I  even got to the main content, I tripped over a typo in the heading of the "About the Reviewers" section (they left off the "s"). Granted, I wasn't an English major, but they are a publisher. Stuff like that just bugs me and doesn't make for a good first impression...

So, for those of you with short attention spans (congrats on making it this far), I liked this book. It provides a solid introduction into Drush for beginners while also demonstrating new tips and tricks that all but the most seasoned Drush veterans can learn from (I learned that there's a drush_hook_post_COMMAND() and the very cool fn-hook command provided by the Devel module). Having said this, I still think there's room for improvement - but thankfully not all that much.

First off, this is one of Packt's smaller books, with only 4 chapters and 118 pages. How Packt can still charge $29.99 USD for the printed edition with a straight face is beyond me (the electronic version is currently $15.29). I was a little disappointed by the way the four chapters were broken up. Chapter 1 is the introduction and installation instructions chapter - makes sense, no complaints. 

Chapter 2 ("Executing Drush Commands") covers pretty much everything else that 80% of the book's readers will ever need. While this chapter does a decent job of going through the basic commands that most people will ever need, it felt a bit rushed to me. I was hoping for more examples, sample workflows, and best practices to really show users new to Drush how to best leverage its power. 

Rather than going chapter-by-chapter (yes, I know there's only two left), let me just say that I think the book could have easily been improved by splitting out various sections of chapters into their own stand-alone chapters. A good example of this is the "Drush Site Aliases" section of Chapter 3 and the "Working with Features" section of Chapter 4. There were quite a few sections like this that if they were made into separate chapters, I feel that the book would have been organized in a more meaningful way. I'm not advocating that there needs to be more content in each of these sections (although it would have helped in places,) just some improved organization. 

Diving a little bit deeper, I was surprised by a few additional things as well:

• The information about installing Drush was centered on version 4.5 - granted, Drush 5 was released in the month prior to publication, but knowing that I've been using Drush 5 for as long as I remember, I'm not sure what the harm would've been to use version 5 in the example. The way it stands now, the book feels a little dated. Knowledgeable Drupal developers know that this doesn't matter all that much, but people new to Drush don't.
• I was a little surprised that there wasn't anything about ensuring Drush can make MySql commands. I know that I had to do some manual tweaking on my system to get it working...
• I found some grammatical errors (yes, I submitted them to Packt for the errata section) and some minor "code text" issues. 
• Juan Pablo, you broke my heart. You broke my heart! Why was the Drush Make section so short? Drush Make should have had its own chapter! It coulda been a contender! (my apologies for mixing quotes from two Marlon Brando movies)

Even so, it's a solid addition to anyone's Drupal library, and I'm already looking forward to the second edition!

The success of mentor-protégé relationships driving greatness in all kinds of fields stands the test of time, from Socrates and Plato, to Max Plank and Albert Einstein, Emperor Palpatine and Anakin Skywalker (maybe not the best example), and even Dries and Webchick. Philosophy, physics, and even IT are better, and better recognized, because knowledge was shared and ideas were nurtured.  There are thousands more examples in hundreds of disciplines.

Now is a great time to take a cue from history and apply the mentoring strategy to the Drupal project with a focused effort.  DrupalEasy is ramping up our second Drupal Career Starter Program (DCSP) in August, and one of the enhancements to the program this year is that students are required to put in 5 hours of community time at the direction of a mentor.  In a few weeks, the 20 eager protegés, vetted for technical ability and attitude, will be ready to devote 5 hours per week to the Drupal project at the direction of 20 DrupalEasy Community Mentors (this is where you come in!)

About the DCSP

The DCSP is a 10 week course designed to help those seeking the Drupal life with intensive, hands-on training to get them on track quickly to become part of the Drupal community.  The Fall 2012 session, which begins on August 21, is specifically for out-of-work residents on Florida's Space Coast who have a background in information technology. Twenty students were selected from more than 180 applications to participate in the program which includes:

• 70 hours of classroom training.
• 40 mandatory lab hours.
• Mandatory Drupal community involvement.
• Grant-supported Drupal internships for those technically qualified at the conclusion of instruction with organizations around the country. 

The program is no-cost to students and internship hosts - thanks to funding through the state of Florida.

How Can You Be a Community Mentor?

We're looking for 20 commited community mentors to guide students through the "mandatory Drupal community involvement" portion of the program. A community mentor will be willing to guide a student through becoming an active member of the Drupal community. In any field, mentors help their protegés gain insight, experience and knowledge. We're looking for people who have experience contributing their time and expertise to the community and a willingness to share their experiences and knowledge with others. We expect community mentors to spend 1-2 hours per week working with their student via email, IRC, Skype or any other relevant methods providing directions and support. Protegés will be required to submit weekly reports on their community activities. 

What are the Benefits?

The DCSP community mentor element will really enhance the benefits to students, mentors, and the Drupal community as a whole. Fast-tracking new, contributing members to the community will help us grow not only the volume and level of expertise, but also foster the spirit of being an active Drupal volunteer to those new to the project. Protegés will gain appreciation for and experience as open-source volunteers. Community mentors who maintain projects on Drupal.org can focus their protegés 5 or more hours per week on how to write documentation, test patches, or work in issue queues. They will gain not just valuable karma points for helping new contributors learn the ropes, but helping to grow resources for Drupal with a specific focus on their projects. 

What Can You Expect From Your Protegé?

The community mentor program will begin concurrently with the first week of classes. Obviously, the students will be green at the start, but their skills will grow week by week. The first few weeks will most likely be focused on getting acquainted and sharing your insights on a Drupal career and ways to volunteer. We anticipate that most students will be able to assist with documentation early in the process, then move on to working in issue queues on simple tasks (attempting to reproduce issues and answering simple questions), followed by more advanced troubleshooting and patch testing. Each student will devote a minimum of 5 hours per week working on community tasks at the direction of their mentor.

How Can You Become a Community Mentor?

Click here to apply to be a DCSP community mentor Applications are now closed - we have only 20 students, so we're looking for 20 people with a solid track record in the Drupal community as well as a serious desire to help make a difference in the development of future Drupal contributors.

Lin Clark (linclark on Drupal.org) leaves Andrew Riley, Ryan Price, and Mike Anello speechless with her vast knowledge of RDF, microdata, and the semantic web on this episode of the DrupalEasy Podcast. Lin talks about how she favors microdata (check out her new Microdata module) over RDF, her super-cool Web Taxonomy module, and a bunch of other things that demonstrates why she’s one of the Drupal community’s brightest minds. Other topics covered include Zen 5.0 and Google’s “recommendation” of responsive design.

Five Stories

1. Lin Clark interview - Web Taxonomy module, IBM Developer Works article, Drupal Documentation Web module, Microdata module, Search Engine Rich Snippets (via the Google)
2. Google “recommends” responsive design
3. Why Web Development is Like Building a House
4. Drupal.org Project Retention, Download to Usage by Scott Reynen
5. Zen 5.0 announcement

Picks of the Week

• Mike - 25 jQuery Plugins to help with responsive design blog post by Paul Andrew at SpeckyBoy.com
• Andrew - Commerce Kickstart v2
• Ryan - BEAN API by Neil Hastings (indytechcook on Drupal.org). Example is Relevant Content BEAN by Sean Larkin
• Lin - WSCCI will be implementing two different content export formats to see which fits the use case better: http://groups.drupal.org/node/237443

Sponsor

WebEnabled.com

Site of the Week

The new Drupal Association Store! https://association.drupal.org/store

If you'd like your site highlighted, please submit it at http://DrupalEasy.com/siteoftheweek.

Listener Homework

Try out Lin’s Microdata module.

Follow us on Twitter

• @drupaleasy
• @andrewmriley
• @liberatr
• @ultimike
• @webenabled
• @linclark

If you'd like to leave us a voicemail, call 321-441-3964. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or time-management tips for Andrew. If you'd rather just send us an email, please use our contact page at http://DrupalEasy.com/contact