I'm wondering how best to handle providing the user the ability to filter channel entries via the front end with the selection of multiple criteria simultaneously - kind of like some real estate sites do, only in my case, I'm looking to filter entries each of which is a cosmetic surgical case (which is mostly photo content, but there is a little bit of text associated with each as well). The user needs the ability to filter according to procedure, male/female, weeks post-op, and possibly other filters that get added down the line.

I had been planning to have procedures as entries and cases as entries, then using Playa relationships to tie them together, but the fact that i need to be abel to offer multiple filter criteria at once (limit view to facelifts, male, 6 weeks post-op, for example) makes that a daunting task from my perspective.

Should I be looking at categories instead (I'm not a fan of categories normally)? Or should I be using a search add-on like Low search. Very interested to hear from the EE community on what would give me the most flexible solution (not to mention which would be manageable to implement).

  • Problem I see is that what if you have an entry that has more than one category.
    – Nick Toye
    Commented Aug 18, 2013 at 17:14

7 Answers 7


If you're going the category route, you could use the native Dynamic Parameters, possibly with Dynamo, to filter entries.

However, using Low Search (or Super Search), you can also filter by Relationship fields (including Playa fields), so that would be more flexible. For example, you can use inclusive filters, allowing to mimic category="1&2&3" as well as category="1|2|3".


You said it's mostly "photo content" which made me think of using something like Quicksand:


You could really filter anything with Quicksand from what I've seen of the demos, including text.

You could then use Tags or native Categories (or both) to setup up the data-id's as per the Quicksand docs to filter off of.

Tag add-ons:


Jason Varga commented about jQuery Isotope appearing to be a more active project and without doubt is definitely a more robust solution. After seeing that I'd say use it over Quicksand if you go this route.


  • 5
    jQuery Isotope is like Quicksand on steroids and more actively maintained as far as I know. isotope.metafizzy.co Commented Dec 4, 2012 at 19:01
  • Yeah on the front end, and in particular in the filtering view, it would be a series of 2-up photo sets (a before and an after). On click, a modal window with larger versions opens. In looking at Quicksand, two questions come to mind - does it allow you to select multiple criteria from within the same set (more than one procedure together, for example)? And would something like that conflict with a responsive page layout, i wonder? Commented Dec 4, 2012 at 19:02
  • Isotope looks pretty wild as well. I have the same questions though. It seems like it's predicated on a single filter within a "filter group". But maybe that's just how it looks in the demo. Commented Dec 4, 2012 at 19:05
  • It appears responsive isn't an issue. How does a filter like this wind up interacting with pagination? There's going to be a pretty large number of cases in the channel (it'll certainly grow as time passes naturally) so is a filter like this really going to work? Commented Dec 4, 2012 at 19:10
  • 3
    Justin Long wrote an article about using infinite scroll in EE which uses a modified version of the jQuery plugin. Isotope uses the same plugin (unmodified). If you apply the modifications I'm sure you could get it working. Commented Dec 4, 2012 at 19:59
   <ul id="filters" >   
        <li class="title">Filter By</li>
        <li class="bullet-item"><a href="#" data-filter="*">Show All</a></li>

        <li class="bullet-item"><a href="#" data-filter=".filter1">Filter 1</a></li>
        <li class="bullet-item"><a href="#" data-filter=".filter2">Filter 2</a></li>
{exp:super_search:results parse="inward" channel="my_channel" status="open" orderby="entry_date" sort="desc" limit="50"}

Then for some jquery:

$(document).ready(function() {

// masonry stuffzs 
var $container = $('.results_list');

  itemSelector : '.collection_image',
  layoutMode: 'cellsByRow',
    cellsByRow: {
        columnWidth: 160,
        rowHeight: 300

$('#filters a').click(function(){
  var selector = $(this).attr('data-filter');
  $container.isotope({ filter: selector });
  return false;


This is all done by using isotope and super search, but you could just as easily do it with Low Search as well.


If I understand you correctly, we do the following:

1) Use a custom form that submits GET variables in the URL to a "results" template we create

2) A plugin we wrote which changes the GET variables into the segment URL structure https://github.com/amityweb/get_segment_redirect

3) Then custom search filters on the channel entries based on the segments:


We also have this working via AJAX to update the search results as the form changes.


I would setup the procedures as categories and keep the cases as entries. Maybe even break the procedures up into different category groups to keep it usable. (ie. Gender Cat Group, Recovery Cat Group, Surgery Cat Group)

Re: filtering the entries, this depends on how many cases there are. If there is going to a couple dozen (<100 or so), I would list all the entries on a page and use the categories as class names on each entry and filter with JS (show/hide). You would then setup a filtering system (selet menus) to drill down on each specific procedures and surgeries.

<div class="case {categories backspace="1"}{category_url_title} {/categories}">
    ...case info...

If there is going to be a ton of cases, I would use a faceted approach with Low Search. Then you can append each category as necessary to filter the entries (cases)


Whenever I have looked into this it always come down to I have a large number or records that need to be filtered and I still need pagination so I need to stay with EE's channel entries loop to handle. The Low Search product is great for this if your filter criteria is based on regular fields. Categories is always a bit trickier due more to EE than anything else. But Low Search is still a great option for that as well. Comes down the number of entries you need to filter by (100 - 500 or more int he 10k or more range). In terms of performance, category filtering of entry lists is always going to be slower.


I don't have any experience of this myself, but came across this question asking about Backbone which links to an EE site with filtering that sounds similar to what you're talking about.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.