Active-Filtering of the Session List in Fiddler2

I use Fiddler2 daily – it’s one of the greatest debugging tools I’ve ever come across. You can hammer into the traffic coming and going across the tubes and tamper with the data as you like. You can substitute alternative local data in the place of remote server responses. You can modify headers on the fly. And this doesn’t even begin to scratch the surface of all you can do.

One of the problems I have is that, like many of you I’m sure, my browser is hardly ever doing one thing. Although I may be trying to debug a web-app, I may also be tied into my GMail inbox, streaming some music over Turntable, or watching the flow of tweets glide across @jonathansampson. All of these items cause sessions to be logged in Fiddler, adding a whole lot of noise to what I’m trying to work on.

So what do you do when you have specific hosts that you want to track? You make use of the Filters tab.

This highly-customizable tab will provide active filtering of the sessions coming across your screen. You can instruct it to show only intranet traffic, or only internet traffic. You can explicitly ignore particular hosts, or you can ignore everything but a select few. As my earlier summary of Fiddler didn’t begin to scratch the surface, neither does my explanation of this panel begin to touch on all that the Filter feature is capable of.

Have a look.

What I’ll be looking at here is the first part, the hosts section.

For starters, we need to click the “Use Filters” check-box to enable this feature. Now in my particular situtation all I want to see is anything that comes from a particular domain, such as This would include any subdomains as well.

The first thing I will do is select “Show only Internet Hosts” from the first dropdown. From the second dropdown, I’ll select “Show only the following Hosts”. This enables the textarea below, which will take a series of expressions or explicit domains to watch for.

Insert * and you should see the textarea turn yellow, informing us that “Changes not yet saved.” At this point, click the Actions button to the top-right, and select “Run Filterset now”. If you already had sessions from your target domain in your session list, those should be all you see in there at this point.

From this you can infer how to go about blocking only particular domains, and various other things. You might even dare to venture into the rest of the filter options, creating a highly-customized instruction set. If you do, be sure to save your filter from the same Actions button we used to run the filterset.

I find this to be an enormously helpful feature, and I’m sure you will as well. Now if you’ll excuse me, I’ve got some work to do and very little noise preventing me from getting it done, thanks to Fiddler.

Creating Your Own Custom jQuery Filters

Chances are you have probably used custom filters in jQuery from time to time to save on verbose selectors. For instance, if we wanted all of the buttons, selects, inputs, and textareas within a form we could do the following:

$("button, textarea, input, select", "#myForm");

You can see how that quickly piles up and gets a bit heavy. jQuery natively provides us with the :input filter which grabs all form elements:

$("#myForm :input");

While these both do the same thing, it’s far easier to call :input than it is to construct a large selector containing all of the particular form elements we can remember at the time. There is a bit of  a performance issue with things like :input though, since they have to cycle over all potential elements. That’s why it’s wise to limit our load by providing some context, in this case we’re looking only within #myForm.

While we can do a lot with what jQuery brings out-of-the-box, we’re capable of doing so much more using some of the tools it provides us with.

You’ve likely used .filter to sift through your elements before applying some effects:


The filter method can take a string expression like :visible and determine which of the div elements meet its demands, and which don’t. Those that don’t will be dropped, and all remaining will have .hide called against them. This method can take a function as well:

    return $(this).text() === "Foobar";

Here we are manually sifting through the elements based upon some examination of their properties. We return true or false, depending on whether the current element being evaluated has the text “Foobar” or not. This solution isn’t very flexible though, what if I wanted to check different things for different strings?

Fortunately jQuery exposes itself in such a way that we can extend its base filters and add our own.

Our focus from here will be on $.expr[“:”]. Within the jQuery function ($) is an object called expr. This object has objects within, one of which is called “:”. This object is where we will place our new method, and provide the necessary functionality to determine which elements pass, and which fail.

$.extend($.expr[":"], {
    exactly: function(){
        return true;

With nothing more than the above, we can already use our filter:


Granted, it doesn’t do anything, but it doesn’t blow up in our face either! As is the case with most callback methods, the element currently being handled is referred to as this. With that, we could already perform some logic:

$.extend($.expr[":"], {
    exactly: function(){
        return $(this).text() === "Foobar";

Of all the div elements we’re cycling over, only those whose text content loosely equals “Foobar” will be kept, while all others are discarded. But again, who wants to hard-code “Foobar” into the definition of the filter? Wouldn’t it be better if our filter worked like :contains in that it took some parameters?

It is at this point we need to look at the arguments passed to our function. We can do so by logging the arguments object from within:

$.extend($.expr[":"], {
    exactly: function(){
        console.log( arguments );


In our console we find the following:

[<div>​Hello World</div>​,   0, Array[4], NodeList[3]]
[<div>​Hello, World</div>​,  1, Array[4], NodeList[3]]
[<div>​Hello, World.</div>​, 2, Array[4], NodeList[3]]

My selector evaluated three div elements. The first argument passed to my function is the element itself. The second is the index of the element. Third is an array of details about the selector itself (more about that in a minute), and the last item is a NodeList of all elements being evaluated.

In this particular instance, our selector array looks like this:

[":exactly", "exactly", undefined, undefined]

We see it has a reference to the filter, the term used in the filter, and then two undefined values. If we were to modify our filter a bit to accept a parameter, we would see the following:

[":exactly(Foobar)", "exactly", "", "Foobar"]

The first value is our entire selector. The second is our filter name, third in this case is empty (though if we wrapped our term in single quotes, this entry would be a single quote as the outer-most single-quotes would be removed from the last item in this array), and last is the actual parameter passed in. Armed with this knowledge, we can then finish our custom filter:

$.extend($.expr[":"], {
    exactly: function( element, index, details, collection ){
        return $(element).text() === details[3];

At this point, we can now select any element based on its text value:

$("div:exactly(foo), p:exactly(bar)");

We now have a reusable solution to a common task.

Finding and Linking to Adjacent Posts with Same Custom Key/Value Pair in WordPress

Today I continued working on merging multiple custom post types back into regular posts, and differentiated them with a custom key/value pair. Some of these old post types would link to their adjacent siblings – videos to previous and next videos, cartoons to previous and next cartoons, etc. With these posts no longer being a custom post type, a video would be linking to whatever post preceded it, which would be an article, cartoon, or any number of things – this wasn’t good.

I wasn’t thinking this would be too much of an issue, after all, don’t we have the freedom to provide constraints to functions like previous_post_link() and can’t we tell functions like get_posts() to return only posts whose ID is greater than or less than the current post id? I was wrong on both assumptions – kinda. You do have the freedom to create some constraints on previous_post_link(), but only at the category level. That means if I wanted videos to only link to videos, I would have to use category names as some form of post type declaration, and I’m not about to do that. As for get_posts(), you cannot use any less-than or greater-than logic in relation to the present post ID.

What now? The solution I ended up going with was found in filters, specifically a custom filter tied to the “posts_where” filter. This idea comes from the WordPress documentation on the query_posts() function which provides an example of how to get posts whose date is within a timespan.

So the filter I ended up creating looks like this:

function filter_where_prev( $where = '' ) {
  global $post;
  return $where .= " AND ID < " . $post->ID;

I should note that that this code does in fact reside within single.php. The post id used will be from whatever post is presently residing in the $post variable. Next, we add this filter onto WordPress’ native filter. We’ll do this via the add_filter() function.

add_filter( "posts_where", "filter_where_prev" );

At this point we can now leverage the inherent power of the query_posts() function to tie things up. Remember that I wanted to restrict my results to posts that contain a specific key/value pair. Fortunately, this is something that query_posts() can indeed help me with:

query_posts( $query_string . "&meta_key=foo&meta_value=bar" );

Be sure to set your desired order and orderby criteria as well. I’ve left those out of my example for brevity.

With our new query established, we can proceed to run through our own micro-loop:

if ( have_posts() ) :
  while ( have_posts() ) : the_post();
    // Do whatever you like here
    // <li><?php the_title(); ?></li>

Once we’re done building a list of references to older (or newer) posts, we need to clean up a bit. We don’t want future queries to use our filter, so we need to remove that. Additionally, we should reset our query as well:

remove_filter( "posts_where", "filter_where_prev" );

Voila! That’s it. Now to do this for both the previous and next items, I had to create two filters. Be sure to remove any filters you create immediately after using them, and always reset your query!