How to Synchronize Social Media Shares, Counts, and Comments Across HTTP and HTTPS

Social Media

The Issue

I use a social media, sharing, or commenting plugin and it shows different data on HTTP and HTTPS versions of the same page/post.

Viewed via HTTP

Viewed via HTTP

Viewed via HTTPS

Viewed via HTTPS

Why Does This Happen?

We build a lot of sites that use social media sharing and commenting plugins, such as:

And if you really want to boil it down to the basics, each of these plugins essentially does the same thing: associate data (comments, share counts, likes, etc) with a specific URL. Pretty simple, right?

The issue described at the very beginning of this article arises because HTTP and HTTPS versions of the same page look like two separate URLs to most of these plugins.For all intents and purposes, these two URLs are treated as separate pages by most plugins, even though they point to the exact same content. That little ‘s’ makes all the difference.

I imagine there are times when this separation is desirable, however we typically want HTTP and HTTPS versions of a page to be treated the same, so that all comments, likes, shares, etc. appear the same, regardless of which protocol is being used in the URL. If that’s what you’re looking to do, then read on. . .

The Solution

To solve this problem, we essentially have to do two things:

  1. Get the HTTP version of the current page/post URL.
  2. Pass this URL to the plugin.

1. Get the HTTP URL

This is the easy part. We generally use the following bit of code (which can be placed in functions.php):

In this snippet, we’re doing two things:

  1. Defining a function, get_http_url( $url ), which converts any URL to HTTP.
  2. Creating a shortcode, [http-url], which outputs the HTTP version of the current post/page URL.

Note: We could have combined these into one simple shortcode, however I prefer separating each bit of functionality out into it’s own function, so that we can use them later if so desired.

2. Pass the HTTP URL to the plugin

Now that we can generate the HTTP version of a post/page URL, we need to basically tell our plugin to use this URL (always HTTP) instead of the auto-generated URL (HTTP or HTTPS). How we accomplish this varies from plugin to plugin, so we’ll outline the basic steps and then give two examples below.

The Steps

  1. Figure out how to inject your HTTP URL in place of the auto-generated URL used by your plugin. Good plugins will have a well-documented way to do this. Decent plugins will have a way to do this. Bad plugins will have neither a way to do this, nor documentation (if this is the case, time to switch plugins).
  2. Use the shortcode you created above to insert your HTTP URL.


We’ll look at two examples: Share Buttons by AddThis and Facebook Comments Box.

Example 1: Share Buttons by AddThis

Share Buttons by AddThis
By default, this plugin will automatically use the current post URL to send and retrieve associated share counts. Fortunately, this plugin falls into the “good” category, as it provides a simple method and clear documentation for overriding the default URL using the addthis:url attribute.

So, say we’ve created a text widget that displays our share buttons. Out of the box, the HTML looks like this:

If we want to ensure that our sharing buttons will always reference the HTTP version of a page’s URL, and likewise ensure that our share counts are the same regardless of which protocol we’re using to view the page, then we can easily use the addthis:url attribute along with our [http-url] shortcode like so:

NOTE: you’ll need to make sure shortcodes are enabled inside widgets, which you can do by adding add_filter('widget_text', 'do_shortcode'); to functions.php.

Presto! Our share counts are now the same whether we’re viewing HTTP or HTTPS.

Example 2: Facebook Comments Box

This plugin is a little trickier, and falls somewhere between “good” and “decent”. The plugin does provide us with a handy filter, facebook_rel_canonical, however the documentation is pretty tough to track down. According to the plugin’s readme.txt file, the facebook_rel_canonical filter “affects Open Graph protocol URL definitions, URL references sent in Open Graph actions, and more.” Kind of obscure, but sounds like we’re in the right place.

So, whereas before we we’re simply outputting some custom HTML, this time we have to use WordPress’ native filters API to substitute our HTTP URL for the plugins default URL:

Just include this snippet in functions.php and you’re ready to go! Comments will now all be associated with the HTTP URL of any given post/page.

In Conclusion

While the details may vary depending on what plugin you’re using, the essential principals remain the same:

  1. Get the HTTP version of the current URL.
  2. Pass this URL to your plugin.

I find that sleuthing around different plugins to figure out how to pass in my custom URL is actually a pretty enjoyable (though sometimes time-consuming) task. I inevitably learn more about how the plugin works, and usually discover a handy trick or two along the way.

And if you run into a brick wall and just can’t figure it out, always feel free to file a support request or email the plugin author.

And if that fails, you can always contact us – we love a good challenge.

And if that fails. . . well. . . time to switch plugins 🙂

New Mm Theme: Trestle

[box type=”download”]


A handy boilerplate child theme for serious Genesis developers.

Trestle takes a lot of the grunt work out of building sites using the Genesis Framework, providing quick and easy-to-implement solutions to common problems and repetitive tasks. We’ve taken Genesis’ rock-solid foundation, integrated mobile-first CSS, responsive navigation, a full-featured settings panel, and much more. Download. Install. Enjoy.

View Demo » Download »[/box]


Trestle: A handy boilerplate theme for serious Genesis developersTrestle includes tons of helpful features such as:

  • Centralized control panel (Genesis → Theme Settings)
  • Responsive navigation menu
  • Mobile first CSS
  • Custom control over post info and meta
  • Multiple page layouts
  • Auto-generating primary navigation
  • Ability to auto-install your favorite plugins
  • Helpful theme jQuery
  • Compatibility with Genesis Extender plugin
  • Optional link icons
  • Built-in shortcodes (columns, buttons, Font Awesome, etc)
  • Front-end styles appear in editor as well
  • And more!

Still to come. . .

There are some features still on the horizon as well (feel free to add a pull request if you’re interested in contributing):

  • SASS support
  • Direct logo implementation (non-CSS)

Plugin Review: blogVault

I’m just going to come right out and say it: blogVault is my new favorite way to backup, migrate, and restore WordPress websites.

We stumbled upon blogVault – or rather, it stumbled upon us – when blogVault founder Akshat Choudhary paid a visit to one of our Bay Area Web Freelancer Meetups. Long story short, Akshat demoed blogVault for us, it looked good, we signed up for a trial, and then. . . well, here’s what we found:

As Easy As It Gets

blogVault - adding a new site

Adding a new site to blogVault

One of blogVault’s defining features is its simplicity. Installing and using blogVault can all be managed from the blogVault admin dashboard. Just click the “Add Site” button, enter the URL and admin creds for your site, and blogVault will automatically install its plugin and start backing up. It’s as simple as that.

And every step of the way is surprisingly simple, which has been a welcome surprise.

Clean & Clear Interface

blogVault does come packaged as a plugin to be installed on your WordPress site, however it is different from most plugins in that all site management/interaction happens outside of the WP dashboard. Instead, you log into blogVault’s own dashboard ( to manage all your sites from one centralized location. I can see how some might like the ability to manage site backups, restores, and migrations from directly within WordPress, but I’ve been pretty content with using blogVault’s dashboard on its own.

blogVault - dashboard

Sites in the blogVault dashboard

The blogVault dashboard displays each site along with its backup status and a number of actions (backup now, test restore, migrate, etc). The interface clearly puts all the options right out in front of the user, and makes it very easy to check the status of a site (last backup, current backup progress, etc) without having to dig.

Backups, Restores, & Migrations

It goes without saying that a good backup plugin should just work. No ifs, ands, or buts. Unfortunately, this has not always been our experience in the past. With blogVault, however, we’ve had a remarkably high success rate (and we’re currently using it to manage over 100 sites). Backups automatically run every 24 hours and can be manually triggered at any point in time. If something goes wonky on a site and you need to restore a backup, you can just click the “Auto Restore” button (or “Test Restore” if you’d like to see what the backup looks like before officially restoring), and that’s that. blogVault also adds a nice feature in that you can download any previous backup (files, database, or both) in case you want to do things manually.

blogVault - migrating

Migrating a site with blogVault

Similarly, migrating sites is a piece of cake. We build most of our sites locally or on dev servers, and when it’s time to take the site live we need to migrate it to the final server and/or URL. In the past, this meant downloading all files, exporting the database from the dev site, uploading the files to the live site, importing the database to the live site, running a serialized search and replace script to correct URLs in the database, and praying that nothing went wrong during the process. With blogVault, the process is simplified immensely. After clicking the “Migrate-Site” link, users are prompted for the target site’s URL and FTP credentials, and that’s pretty much the whole process. blogVault ports all files and the database, and automatically replaces all instances of old URLs with new ones. This is hands down the easiest that migrating a site has ever been for us here at MIGHTYminnow.

Helpful History

Changes are highlighted in the history panel

Changes are highlighted in the history panel

One of our favorite blogVault features is the history panel. Many backup solutions allow you to see a site’s backup history, but blogVault does a few nice things that make it stand out. For one, plugin and theme changes are highlighted, which can make all the difference when troubleshooting a broken site. Additionally, blogVault allows you to add custom notes to each backup. We use this feature quite often to do things like explicitly mark a backup right before performing some operations on the database, or to make note of the first clean backup after fixing a broken site – essentially setting backup waypoints to guide us in the future.

Fantastic Support

I tend to think that the folks at blogVault have treated us especially well because we’ve provided them with a lot of feedback and testing, but I have to say that blogVault support has been amongst the best I’ve ever received. Support requests are handled quickly and efficiently. Akshat and his team have repeatedly gone the extra mile. Whereas other premium services and hosts sometimes push issues back on us with generic suggestions, the blogVault team has typically taken it upon themselves to just plain fix an issue when we face it. They’ve also been surprisingly responsive to feature requests and bug reports.

Issues & Bugs

blogVault - layout weirdness

Some wonky aesthetics

Any good review will cover a product’s issues/bugs, and blogVault does have its share of quirks. The good news is that, functionally, the product has proved itself completely sound in our experience. The issues we have encountered are primarily aesthetic in nature. A few examples include:

  • In the dashboard, some sites seem to get thumbnails and some don’t. And at various screen resolutions, things overlap in strange ways.
  • Progress indicators can act a bit unpredictably when migrating and/or backing up a site. During one migration, the indicator seemed to be stuck at 43%, then suddenly jumped to 118%, before coming back down again to just below 100%. The migration completed just fine, but there was some funny math happening in there somewhere.
  • When migrating a site, the progress indicator overlay covers everything else, so you’re stuck waiting until the migration is complete and can’t perform any other actions on other sites.
  • For a while, backups in the history panel seemed to be mixing up timezones. We’d backup a site, and the timestamp would say it was backed up “in 8 hours” – this appears to have been fixed shortly after we submitted a bug report however.

Bottom Line

Thumbs Up!All in all, the issues we’ve encountered with blogVault are pretty trivial when compared to the immense amount of time and hassle we’ve been saving. And the product only gets better – Akshat and his team have been extremely responsive and proactive about responding to bugs and implementing new features, and we’re excited for the improvements yet to come. We highly recommend signing up for a free trial and testing out the awesomeness of blogVault for yourself.

Try out blogVault →

WordPress Captions – How to Remove Default 10px Padding

One of the things WordPress does right out of the box that we don’t always like is automatically add an extra 10px of width to all images with captions. This is great if you want to preserve the default .wp-caption styling with a nice 5px of padded gray around the image, but if you change your CSS then you can end up with something not so great, like this:

Why the extra padding!

Well here’s a quick workaround using the newish img_caption_shortcode_width filter:


Mm Plugin: WP Hotkeys

WP Hotkeys

WP Hotkeys provides time-saving keyboard shortcuts to help you quickly navigate the WordPress dashboard.

Download Now »

WP Hotkeys helps you navigate your dashboard as quickly as possible with fully customizable keyboard shortcuts. After installing WP Hotkeys, you will see the default hotkey hints display in brackets next to each standard menu item in the admin. Typing a hotkey will access the associated top-level admin menu item (e.g. Pages), and will display any submenu items and activate their associated hotkeys (e.g. All Pages, Add New). At any point you can use the arrow keys to navigate between menu items (left/right will enter/exit submenus), and the enter key to navigate to the active (underlined) menu item.


  • Works right out of the box with built-in default hotkeys for each standard dashboard menu item.
  • Hotkey hints next to each menu item help you remember your shortcuts (can be toggled on/off).
  • Fully customizable – define your own hotkeys.
  • Lightweight – less than 4kb minified jQuery.
  • Built-in warning to let you know if you have duplicate hotkeys.

Coming Soon…

  • Export/import your favorite hotkey setup
  • Define custom URL/hotkey pairings

Equal Height Columns with jQuery

Equal Height Columns with jQueryThere are a ton of great solutions out there for creating equal heights columns – so many that it can get a bit daunting to choose one. Here’s a simple jQuery snippet we’ve started using when CSS alone won’t suffice. Thanks to Rob Glazebrook for the building blocks, to which we added some special functionality including binding the equal height-ing to orientation change (for mobile) and window resize, as well as the option to specify a breakpoint above which the functionality should work.

How to Get URLs for WordPress Admin Menu Items

Get WordPress admin menu item URL'sRecently, we were working on a project in which we needed a reliable way to get URL’s for WordPress admin menu items (Dashboard, Posts, Plugins, Tools, etc). Despite our best searching efforts, we simply could not find an answer – seemingly no existing function to accomplish this task. So we ended up digging into menu-header.php, the file that generates WordPress admin menu, and creating a function of our own.

get_admin_menu_item_url() retrieves a URL based on an admin menu item’s associated “file”:


To use get_admin_menu_item_url(), you first need to figure out the “file” that corresponds to the menu item you’re interested in. This file name can be found by accessing items in the global $menu and $submenu arrays – which hold the top- and sub-level admin menu items. Each of these items is an array with the following key/value pairs:

0 – name
1 – capability
2 – file
3 – class
4 – id
5 – icon source

What we’re interested in is the file, which is the unique identifier that will allow us to retrieve the menu item’s URL. So when all is said and done, your code might look like this:


What is Mobile First CSS and Why Does It Rock?

We throw around the phrase “mobile first” a lot here at MIGHTYminnow. It factors into many of our discussions and plays an important role in pretty much every site we build. We even created the Genesis Mobile First Child Theme, which is dedicated to making it as easy as possible to go mobile first when working with the fantastic Genesis Framework. Well if you’re wondering what “mobile first” means and why it rocks, keep reading.

What is Mobile First?

Lots of different people define mobile first in lots of different ways, but when we talk about building a mobile first website it basically boils down to two things:

  1. Philosophically: Optimizing the experience for mobile users as much as possible. In other words, putting the needs of mobile users first.
  2. Codily (we just made that up): Writing CSS in such a way that smaller (mobile) devices can access their styles without having to wade through styles written for desktop devices. In other words, writing the mobile styles first. (“First” means before the media queries that define the look of the site on larger displays – media queries are one of the hallmarks of “responsive design.”)

Now, there are tons of considerations that go into making this magic happen, and we’ll get to that in a minute. But first things first. . .

Why Go Mobile First?

There are a few key reasons why mobile first development is a good idea:

Mobile vs Desktop Usage Over Time

Mobile vs Desktop Usage Over Time

  1. Mobile traffic is growing. . . fast
    The number of website visits coming from mobile devices is ever-increasing, and is predicted to surpass desktop visits in 2014. Bottom line: mobile viewership is growing and so is the demand for mobile-friendly websites.
  2. Mobile experience ≠ desktop experience
    Phones and tablets are different from desktop machines in so many ways (screen real estate, processing power, connection speed, etc), and their different limitations and capabilities warrant different solutions. Bottom line: designing for ALL devices, and coding in the way that makes the most sense for each of them, is better than designing only for desktop devices.
  3. People will leave and never come back
    Tons of folks have written on the negative effects of poor site design/functionality, particularly in regards to site speed. Bottom line: if your site doesn’t work well on mobile, you’ll lose users.

How Do I Code Mobile First CSS?

There are tons of ways to optimize mobile users’ experience, and if you’d like to learn more about all of them you should definitely check out Luke Wroblewskis’ excellent book: Mobile First. In this post, however, we’re going to focus primarily on CSS – our bread and butter. With that in mind, here are some mobile first CSS best practices we use on a daily basis:

Min-Width Media Queries

This is probably the most common question we get when talking about mobile first: why does it matter whether I use min-width or max-width media queries?

min-width media queries in actionUsing min-width media queries at the end of your style sheet means writing all of the common (meaning used by all devices) CSS first. All of the rules that you want phones and tablets to see are front and center, with larger screen caveats in the media queries below, in order of increasing screen size. Writing the common-to-all styles first ensures that mobile styles get loaded without desktop styles mixed in – which can significantly improve the mobile experience.

Mobile first CSS is written like this:
Styles for mobile and styles that are common to all screen sizes
(no media query)
Media query with a smallish min-width breakpoint
e.g. @media (min-width: 400px)
Media query with a slightly larger min-width breakpoint
e.g. @media (min-width: 600px)
Media query with a larger still min-width breakpoint
e.g. @media (min-width: 960px)

One way to think of it is that you start with a mobile base and build up (or out, if you think in terms of widths).

It seems like, with the introduction of responsive design, that a lot of folks defaulted to building the desktop version of their site first, then proceeding with max-width media queries at the bottom of their CSS in order to “undo” these desktop styles for mobile devices. You’ll see this approach used in TONS of responsive WordPress themes. We think this is because we’ve gotten so used to visualizing design from a desktop-first standpoint. “I’ve got my big screen, and as I shrink it down to tablet and phone sizes I need to know the maximum width up to which I should apply my mobile styles.” That’s thinking desktop first – essentially catering to desktop machines and treating mobile devices as an afterthought.

Content is like water

Photo by Stéphanie Walter / CC BY

But here’s the catch. Let’s say our style sheet is massive (although in an ideal world we would minify and concatenate all our CSS), and our media queries are at the very bottom (which is good). Writing the desktop layout first – float this, position that – and then undoing that floating, positioning, etc in the media queries means that you are first building your desktop layout, and then deconstructing it for mobile. To do this, you are writing more code, and doing it in the order that makes the least sense to the devices that need the most help in terms of connection speed. And if you’re viewing the site on your phone, you’re going to be seeing the desktop version of the site until the CSS is almost entirely parsed. We’re not talking very long here, milliseconds at most, but we’ve seen plenty of sites on which this moment of incorrectly-styled content is visible – and distracting. You can read more about this eternal nemesis of developers the world around: FOUC.

Using min-width media queries allows you to build your design from mobile sizes on up, thus shifting the burden onto non-mobile machines. Now we’re catering to the limitations and capabilities of different devices (non-mobile devices typically load/render CSS faster than their mobile counterparts). Historically, the trend has been that mobile devices have less processing power than their non-mobile counterparts. While this gap is shrinking, why not make sure the less performant devices get their CSS faster?

The other reason to use min-width media queries is that it really helps us get in the mindset of. . .

Progressive Enhancement

Progressive enhancement essentially means adding more cool stuff (CSS & JavaScript, usually) as our device can handle it. It’s sort of the inverse to the concept of “graceful degradation,” which means that we start with all of our great functionality and design components, and remove them as needed for devices/browsers that can’t handle them. In terms of taking an approach to mobile first CSS, we can often achieve better performance on average by implementing a mobile first approach. Again, remember that we want to switch as much of the work as possible away from mobile devices and onto their (typically) more performant non-mobile counterparts.

So we start with the simplest core features, and we add more as the user’s device can handle it. This not only helps us follow our favorite KISS practices, it also results in better performance and user experience.

Content (Not Device Width) Determines Breakpoints

I can’t tell you how many sites we see with the following breakpoints: 320px, 480px, 768px, 1024px. As you may have noticed, these are the exact dimensions of the ever popular iPhone (pre 5) and iPad. The folks that wrote this CSS had one thing in mind: making sure their breakpoints aligned perfectly with specific devices. But what happens when a new device with new dimensions is released, the iPhone 5 for instance? Or a new Android tablet or the MS Surface? Suddenly our breakpoints don’t make as much sense and we’ve got to modify our CSS to accomodate these new dimensions. New device. New media query. New device, New media query. On and on, ad infinitum. You can see there is a fundamental problem with letting popular devices dictate breakpoints.

Instead, we prefer to base our breakpoints on the natural qualities of our content – essentially paying attention to when each element “wants” to be restyled. A great example of this is styling navigation menus.

On the MIGHTYminnow site, our navigation appears as a grid on mobile devices (try dragging your browser window to a smaller width to see). As the screen size increases, we simply pick a point at which the content itself would look better in a new formation, and that’s our breakpoint! We keep working our way up until we’ve reached desktop size, and that becomes our final min-width media query. It’s pretty simple, really, and we’ve created CSS that is future-proof, ready for any device size. Honestly, this organic approach flies in the face of a lot of the current grid-based frameworks and theories, but it is really the only thing that makes sense to us – plus it’s really not that hard to implement. If content is king, why not let your content define the point at which your layout changes?

Relative Units & Percentage Widths

Mobile first development, done well, is synonymous with flexibility. Using relative units (em or rem) and percentages (particularly percentage-based widths), allows you to create CSS styles that flow smoothly across devices and screen sizes. Almost more importantly, they make future changes that much easier. Imagine, for a moment, that you’ve hard-coded your content-area/sidebar widths and font-sizes with something like this:

Seems fine, right? But what if you suddenly realize your media query needs to trigger at 1060px, not 1000px? Now you’ve got to manually change the pixel widths of your content-area and sidebar. Or say you decide you need to bump up all font-sizes across the board. Here we’re just looking at two elements, but imagine the potential impacts on a site with hundreds, or even thousands, of CSS rules. That can get pretty daunting pretty fast. With relative units and percentage-based widths, however, far fewer modifications are needed. The proposed changes above are as simple as:

Notice that we’ve switch our widths to percentages, and the font-sizes to relative values. Now, you can see how our widths will work no matter where our breakpoint occurs, and our font-sizes can be changed across the board just by changing the <html> element’s font-size.

The Little Things

Mobile first CSS is often about improving the little things, which can make a big cumulative difference in the end. Here are some “little” best practices to keep in mind:

  • More Gradients & Font Icons, Fewer Images
    If you are looking for some new best friends in the web world, than might I recommend CSS3 gradients and font icons. These methods not only pack some serious design punch, they also help you minimize your HTTP requests and save on bandwidth – surefire ways to improve overall site speed and general user experience. Images, on the other hand, are a surefire way to increase load times and leave your users hanging, particularly on less performant mobile devices.
  • Smaller Images at Smaller Sizes
    Serving device-appropriate images is a great way to improve a site’s performance across all devices. With background images, this is a pretty straightforward task. As you move up through your CSS breakpoints, you can simply load larger versions of these images, changing your CSS styles accordingly. For inline images, this can get a bit trickier. The same concept applies (smaller images for smaller devices), but solutions typically require a JavaScript polyfill to dynamically replace/load images as needed. If you’re interested in this method, you might want to check out the following:

What’s The Catch?

Mobile first sounds pretty good, right? So why isn’t everyone using it?

Old Habits Die Hard

The good news is that mobile first’s main obstacle is simply that we’re not used to it. For a long time we’ve been designing websites for non-mobile devices simply because mobile devices never played a significant role in viewership. Consequently, we’ve picked up some deeply ingrained site-building habits, processes, and philosophies along the way. A mobile first approach requires us to flip some of these habits on their head (e.g. designing with a phone screen in mind and working up to desktop, instead of vice versa), and this can certainly lead to some growing pains. Worth it? Definitely. I mean, table based layouts weren’t easy to let go of, but we’re all glad we did.

Design problems

“The designer doesn’t understand mobile” or “there’s no budget for extra (mobile) comps”

One thing we’d like to stress is that mobile first coding doesn’t have to mean generating special mobile comps, although that sounds luxurious and lovely. Even if all you have is a desktop design, you can create a great, responsive website (have a look at our case study for Rocket Dog Rescue). We only ever have our designers generate desktop designs, and we use them to make responsive websites. All you need to do, in our opinion, is to be very conscientious when adding widths, floats and other column inducing code. As you are coding your “desktop” comp, isolate any column widths and layout stuff in media queries at the bottom of the page, as well as any outrageous heading font sizes that don’t look good when you drag your browser down to phone sizes. Do some browser dragging as you go, and pop over to or responsinator for validation. If you treat your comp as a guide, and keep on top of the way the site looks on mobile as you code, you can come away with a “pixel perfect” desktop display and appropriate mobile layouts without a ton of additional effort.

Side Note: Polyfill Needed

Alas, certain Browsers-That-Must-Not-Be-Named still don’t natively support CSS media queries, and will need an extra polyfill to accurately render your mobile first CSS. Good thing there are some great polyfills available:

In Conclusion

Mobile first. Learn it. Use it. Love it. Taking a mobile first approach is a great way to ensure that your site looks and performs optimally across the board.


Mobile First, by Luke Wroblewski

Creating a Mobile-First Responsive Web Design, by Brad Frost

Mobile First Design: Why It’s Great and Why It Sucks, by Joshua Johnson

Mm Plugin: jQuery Responsive Select Menu

jQuery Responsive Select Menu

Automatically turn your standard WordPress navigation menus into responsive select / drop-down menus when the screen is below a certain width.

Download Now » See Demo » GitHub Repo »

jQuery Responsive Select Navigation Menu

The responsive select menu in action.

jQuery Responsive Select Navigation Menu

Settings for the responsive select menu.

jQuery Responsive Select Menu gives you a simple way to make your navigation menus responsive for mobile devices like phones and tablets (iPhone, Android, Kindle, etc). The plugin lets you specify a width at which to turn your normal menus into responsive, drop-down select menus – a proven method for solid, responsive navigation.

You also get specify some other handy settings including:

  • CSS class/ID selectors to specify exactly which menus to affect
  • The width at which to switch from normal to responsive navigation menus
  • The character/spacer to add to sub-items in your drop-down select menu
  • A “dummy” first term to add to the top of your drop-down navigation (e.g. ⇒ Navigation)
  • Whether to show the current page, or the top-level “dummy” item, as the default


MIGHTYminnow’s Favorite WordPress Plugins: Widget Context

MIGHTYminnow's Favorite Plugins: Widget ContextOur next stop in MIGHTYminnow’s favorite WordPress plugins is Widget Context. This plugin allows you to specify exactly where your widgets do and don’t show up. Using widget context, you can tell a widget to only appear on a certain page, in a specific section (e.g. all pages under About Us), or everywhere on your site except for in certain circumstances (like excluding posts from 2008). We use Widget Context on just about every site we build to do things like the following:

  • showing related blog posts only on blog pages
  • adding page-specific related content
  • showing other event links on event pages
  • adding related testimonials for page-specific products or services

MIGHTYminnow's Favorite Plugins: Widget ContextOne of the big perks of Widget Context is that it adds controls right onto your existing widgets, which means you don’t have to navigate away from your Widgets panel to make changes. These added controls are where the magic happens, allowing you to choose a “context” for your widget in one of two ways:

  1. Checkboxes
    Choose from some common selections like Front Page, All Posts, 404 Error, etc
  2. Target by URL
    Specify a URL pattern (yes, you can use wildcards!) to match

Depending on how many pages you want the widget on your sidebar to show up, you either choose to show or hide the widget on selected posts/pages that match the criteria you’ve selected. If you know that you want the widget on all blog related content, you might choose the Show on Selected drop-down option and check the boxes for Blog Index, All Posts, and All Archives.

The URL targeting feature is pretty handy as well, allowing you to target a specific page, a page and all of it’s sub-pages, and much more. To target a specific page, you use the UNIQUE part of the URL. For example:

  • A single page:
    To add a widget just to this page:, you would include “services” (without the quotes) in the “target by URL” box.
  • Child pages:
    To add a widget to all child pages of services, but NOT services itself, you would add “services/*” (without the quotes) in the “target by URL” box.
  • A site section including parent and child pages:
    To add a widget to the services page and all its children, you would add “services*” (without the quotes and without the slash from the example above) in the “target by URL” box.


  • When entering multiple pages to target, each page goes on one line and you don’t want to have a blank line after the last one.
  • The URLs for pages you target can be complex – adding widgets to a deeply nested page or section works the same as the above, just include the complete string for the unique part of the URL, like: “services/web/hourly”, “services/web/hourly*” or “services/web/hourly/*”

Thoughts? Comments? Questions? As always, we love to hear from you. Check out the comments section below.