In case you find yourself wondering what that could possibly mean, let’s start with a definition (care of Wikipedia):
“…merchandising is any practice which contributes to the sale of products to a retail consumer. At a retail in-store level, merchandising refers to the variety of products available for sale and the display of those products in such a way that it stimulates interest and entices customers to make a purchase.”
Obviously, we’re not talking about the retail, in-store level here, but the concept is still very, very applicable in the e-commerce world. In short, merchandising includes a whole lot of things a shop owner—or content administrator on an ecommerce website—might do to spiff things up and ultimately make customers put more expensive stuff in their cart.
In Hunter Boot’s case, deciding which image shows up first for each product, for example, certainly counts as a form of merchandising. So does selecting what to put in the ‘Complete the Look’ (aka ‘related products’) area for each product, or even something subtler like controlling the order of the color swatches (all three of these, by the way, are things Hunter’s content administrators can and often do update themselves). If you think about it, very little of what you do on the front end of an e-commerce site is not merchandising in one form or another.
In the case of this particular “merchandising” request, however, Hunter was talking about something seemingly quite simple. All they wanted to do was be able to choose the order that products appeared in on the browsing pages of the site. We built an appropriately simple solution, only to fully appreciate its shortcomings and replace it with something much better months later. Here are the details for your amusement and edification.
The Original (Ill-advised) Solution
Here’s what we did the first time around:
1. Added a ‘Weight’ field to product display nodes and assign a number weight to each product.
2. Configured the view that displays the products to sort the products by weight
In other words, you used to see something like this ‘Product Order’ field on the edit page for every product node:
In case it’s not already obvious, this was a less-than-stellar solution for several reasons:
First, it was excruciating to maintain. Suppose you wanted to do something as simple as moving the Original Boots to the top of the list. You used to have to:
a) Find the edit page for the Original Boots node
b) Update the weight field to a low number (hopefully low enough, or you’ll have to do this all again)
c) Hit save before heading back to the original to view to make sure it all worked according to plan.
Heaven forbid you wanted to move a product to a specific place in the list—you first needed to know the weights of the products both before and after, which meant at least several trips to different pages.
A second problem—subtler, perhaps, yet one any true merchandiser would certainly consider a show-stopper—was the lack of flexibility. Specifically, however we decided to arrange the products, we were stuck arranging them that way on every page they appear. For example, if Hunter wanted the latest “Rag & Bone” boots to show up at the top of the main Women’s section, but the classic Original Tall Boots to show up first on the Women’s footwear section—well, they’d be plain out of luck.
The Better Solution
After much sweat and tears, we went back to the drawing board and did it like this instead:
1. Install the DraggableViews module.
2. Follow the instructions in the section titled “Creating a Sorting Interface for a View” in the DraggableViews documentation.
3. Update the permissions on the sorting interface attachment to make sure only admins can see it.
In short, when content editors now go to the page for the products view, they’re able to set the order for all the displayed products without going to another page at all. They just drag and drop to their heart’s content, then click ‘Save’ to finalize things when they’re done.
As for flexibility? Draggable Views has us covered, since it actually stores a unique sort order for every contextual filter (or combination of contextual filters). That means, for example, we can sort the products on the ‘Flats and Sandals’ page and the ‘Footwear’ page completely independently, even though both pages use the same view.
Though that’s all you really need to get this working, we took a few extra steps that are worth considering:
1. Add some simple expand/collapse jQuery so that the draggable attachment stays out of the way when we’re not merchandising (this is included in the animation above—with three products, it’s not really an issue, but with a long list it’s practically mandatory).
2. Enable caching for the view. At least in Hunter’s case, caching is almost a necessity here. Traffic to these pages is relatively high; the content isn’t user-specific or changing frequently; and as on any commerce site, page caching won’t work for any user who has something in their cart already. Of course, the whole draggable setup breaks when views caching is enabled. So, one final step:
3. Install the Cache Actions module and create a rule to clear the cache for this view whenever the draggable views form is submitted (i.e. whenever an admin changes the sort order).
I’d argue that the final result is a content management system looking its finest. Editors have the flexibility to do whatever they want with respect to re-ordering, and it’s easy. It also shows that in making the most of Drupal (and Drupal Commerce), although it might take few iterations to get to a great solution, Drupal, and all of its “open sourceness” provides the power and flexiblity to come up with that solution.
At least, it’s passed the most important test: the content editors have been happily using it for awhile now with no further requests!