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

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 responsive.is 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: http://www.mysite.com/services/, 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.

MIGHTYminnow’s Favorite WordPress Plugins: Events Manager

Events ManagerIf you are an organization that hosts frequent events (like we do), Events Manager / Events Manager Pro is a must have. This is a free WordPress plugin, with an optional “Pro” upgrade if you need to take payments. Events Manager offers a robust array of settings and features, which makes it really easy to create and display events, registration forms, and much more.

(Free) Features We Love:

  • Screen Shot 2013-10-10 at 2.08.24 PMTemplates & widgets
    Events Manager makes it extremely simple to output your events in a bunch of different ways. The plugin comes with great default templates for events list, calendar, and widget views – plus you have the ability to set up your own templates using simple placeholder tags (e.g. #_EVENTTITLE)
  • Google integration
    Google Maps are seamlessly integrated, meaning your guests can see a map of each event location, and can even look up directions from their location – all from within the page they are viewing. Events Manager also integrates with Google calendars and iCal, so your guests can add your events to their personal calendars in one click.
  • Categories and tags
    Just like WordPress’ Posts, you can categorize and tag your events. Additionally, you can output custom lists of particular categories and tags.
  • Create multiple tickets
    If your event has separate prices for members and non-members, or if you have different levels of entry (1-day pass vs. conference pass), you can create different tickets for these groups.
  • Timing and recurring events
    Events Manager really shines when it comes to scheduling your events. The plugin places a huge number of possibilities at your fingertips, including the ability to custom schedule recurring events. Whether your event is all day, 7-9pm, or recurs every Thursday at noon – you’ll easily be able to set it up in Events Manager.

(Pro) Features We Love:

  • Coupon Codes
    You can set up multiple coupon codes for specific discounts (fixed-price or percentage). You can also limit the number of coupons available and/or set an expiration date.
  • Online Payments
    Probably the #1 pro feature is the ability to take payments through PayPal, Authorize.net, and other offline payment methods. We use Events Manager Pro on the MIGHTYminnow site to facilitate class registrations through our payment gateway.

Mm Plugin: Super Simple Related Posts

Super Simple Related Posts

A super simple widget to output related posts based on categories, tags, or custom taxonomies. You get to decide how the posts are related (categories, tags, custom taxonomies), what to show (posts, pages, custom post types), and a whole lot more.

Download Now » See Demo » GitHub Repo »

Super Simple Related Posts

The Super Simple Related Posts widget

The Story

This plugin came about as the result of a recent project in which we needed to output related content on pages and posts in a unique way. We often create a lot of custom post types and taxonomies using Toolset’s amazing Types & Views plugins, and we needed a way to show related content based on specific criteria (e.g. post type and taxonomy).

The other thing we needed was an alternative to some of the many resource-intensive “related content” plugins out there – and make no mistake, there are MANY. Yet a lot of these plugins work their magic by querying your database, running post content through algorithms, and performing processes that put a heavy strain on the server. So much so, that they sometimes get banned from premier hosting companies like WP Engine. So, with all this in mind, we developed this handy plugin and decided to share it with the world.

How it Works

In short, SSRP gives you a widget that can output a list of content related to the current page/post by any category, tag, or custom taxonomy. Let’s look at a real-world example to demonstrate what the widget can do. We recently utilized this plugin on a fundraising site that incorporates several different post types for their knowledge base:

Post Types

  1. Blog Posts (built in WP post type)
  2. FAQs (custom post type)
  3. Articles (custom post type)

. . . as well as a few custom taxonomies shared across these post types. . .

Custom Taxonomies

  1. Life Cycle (e.g. Beginning, Middle, End)
  2. Industry (e.g. Music, Sports, Arts)

So to sum up, we have a bunch of posts, FAQs, and articles – all of which are classified with Life Cycle and/or Industry taxonomies. With Types & Views it’s really easy to set something like this up, and we often end up using numerous custom post types and taxonomies on the sites we build. So in this case, an example of a typical FAQ might look like this:

  • FAQ: How do run a fundraiser for my team?
    • Life Cycle: Beginning, Middle
    • Industry: Sports

So now comes the fun part – related content. We want to display related content in the sidebar of our FAQ, and we want to be able to dictate exactly how it appears. That’s where Super Simple Related Posts comes in. Using this plugin, you can decide what type of content you want to output (posts, FAQs, and/or articles) as well as the taxonomy (category, tag, or custom taxonomy) by which to select related content. Back to our example. . .


Using SSRP, you might choose the following settings (note: these are just a few of the many settings you’ll be able to modify):

  • Posts Types to Include: FAQs, articles
  • Show Posts Related By: Life Cycle
  • Number of Posts to Show: 3

With those settings, your SSRP widget would output the following when viewing the above FAQ on your live site:




As you can see, SSRP give you the ability to add functionality much like you might find on a site like Amazon.com, which offers sidebar suggestions based on the content you’re looking at. Here are other blue shoes for you to look at. Here are more books written by American authors. Here are all the other long-haired crazy cat photos. You get the idea.

In Conclusion

Whether you’re using WordPress straight out of the box, hand-coding your own custom post types and taxonomies in functions.php, or using the awesome Types & Views plugin to work some serious magic, Super Simple Related Posts might be just what you’re looking for. Head on over to the official WordPress.org site to learn more. And, as always, if you have any questions, comments, or feature requests, we’d love to hear from you. WordPress.org: Super Simple Related Posts Plugin »

Mm Plugin: HTML5 Placeholder Polyfill

Without placeholder support

Your form without the plugin (IE 7/8/9 & Opera Mini)

With placeholder support

After installing HTML5 Placeholder Plugin

MIGHTYminnow is proud to announce our new plugin: HTML5 Placeholder Polyfill!

The plugin adds placeholder support for older browsers like Internet Explorer 7/8/9 and Opera Mini which don’t support placeholders natively. We simply took Mathias Bynens’ amazing jQuery placeholder polyfill and bundled it as a WordPress Plugin – the jQuery itself is widely used and well-vetted. In case you’re wondering what a placeholder is, it’s that handy text inside a form input or text area that is often used to suggest what the user should enter (e.g. “Enter your email address”). This functionality can be super handy when it’s working, and can create a major mystery for your users when it’s missing (imagine a form without labels, in which the placeholder text is the only indicator of what the user should enter).

Our plugin guarantees that your users are never left in the dark. To learn more or download it, just visit the WordPress Plugin Page:

Visit the Plugin Page »

How to Make a Custom jQuery WordPress Plugin

We love jQuery. A lot. And we use it a lot too. In fact, on pretty much every site we build, we utilize a common set of basic jQuery snippets that do some handy things (opening external links in a new window, adding helpful classes to list elements, labeling links based on there “href” attributes, etc). Sounds like the job for a simple plugin, right? No need to copy and paste all your snippets on each new project – you can create your own custom jQuery plugin in 4 easy steps:

1. Set Up Your Plugin

First thing you’ll want to do is create a new directory for your plugin. Name it something intuitive, like my-custom-jquery (typically all lowercase with hyphens).

In this new directory, create 2 new files:

  1. my-custom-jquery.php
    The file name should essentially match your plugin name.
  2. my-custom-jquery.js
    Similar naming scheme. We’ve chosen to name our file mightyminnow-custom-jquery.js in the code below.

Now you’re ready for the actual coding.

2. PHP (my-custom-jquery.php)

This is the guts of your plugin – your main PHP file.

This code does a few things:

  1. The first commented bit is a standard WordPress plugin information header. It contains important info about the plugin, such as author, URI’s, and a brief description.
  2. Further down, we have a basic function that does two things. First, it enqueues jQuery (notice the function wp_enqueue_script which is the safe and proper way to include jQuery in WordPress). Second, we enqueue our custom jQuery.
  3. Lastly, we add an action to run the whole shebang. We use the wp_enqueue_scripts hook, which is a good place to include all scripts.

3. jQuery (my-custom-jquery.js)

Now we just have to add our actual jQuery to the .js file we’ve made. Here is the code we’re using – feel free to add your own snippets as well.

As you can see, this jQuery does a number of things including:

  • Opens external links in a new window
  • Adds special classes to image, email, and pdf links (we often use these classes to add small background-image icons)
  • Add special classes to first, last, and parent list elements

This is where you can get creative and add whatever jQuery snippets you like to use on a regular basis. If you have any suggestions, definitely post them in the comments below!

4. Install Your Plugin

At this point, you’re ready to install your plugin. You’ve got two options. The first is just to upload your plugin folder directly to /wp-content/plugins. The second is to create a .zip of your plugin folder and use WordPress’ built-in plugin installer to upload it. Once it’s up and running, make sure to thoroughly test any jQuery snippets you’ve added, and definitely let us know what sorts of cool stuff you come up with.

Questions? Comments? Let us know below!