Tutorial: Using jQuery Masonry with WordPress

This is a short tutorial on integrating Masonry, the jQuery layout plugin, with your WordPress site. We will try to use that jQuery plugin to show a list of posts in a neatly stacked layout, similar to the one I have down here. Here’s an explanation about Masonry, from it’s home page:

Think of it as the flip side of CSS floats. Whereas floating arranges elements horizontally then vertically, Masonry arranges elements vertically then horizontally according to a grid. The result minimizes vertical gaps between elements of varying height, just like a mason fitting stones in a wall.

Here’s a visual explanation, which I took and edited to fit my layout. Pay attention to the numbers, which shows the order of the elements in your HTML code:

Understanding Masonry’s Behaviors

Using Masonry itself is pretty simple, but if it’s the first time you’re using it there can be some surprising behaviors, especially regarding element spacing. Let’s talk about that first.

Masonry allows for two different cases. First is where all elements have the same width, and you should use this:

$('#container').masonry({ singleMode:true});

The second case is where your elements have differend widths. Use:

$('#container').masonry({ columnWidth:200});

Where columnWidth is the width of the grid (in pixel). Masonry will then follow these two rules:

When using columnWidth, then all elements must be placed horizontally at an increment of columnWidth (e.g. for columnWidth: 200, elements will start at 0 or 200 or 400 pixels and so on). This might not be intuitive and does not work like CSS float:

The first element has a total width of 190px and margin-right is 0. At the same time the second element has 0 margin-left, so you will probably expect both to stick to each other. However, since the columnWidth says 200px, then the second element is pushed further and starts at 200px instead.

That will not be the case if we only have one width, though. The next element will be placed right next to the previous one according to the margin between both.

WordPress + Masonry

Okay, coding time. We’ll try to recreate my Latest Links area where all elements have the same width. First we enqueue jQuery and call the Masonry JS script in the theme’s header.php file.

Make sure that wp_enqueue_script appears before wp_head, and the script call appears after it. Here’s a more detailed article on how to correctly enqueue jQuery in WordPress. My Masonry JS is located in a /js folder, yours might be different.

Pretty simple. “Linky” will be the container div that will call the Masonry function, and “boxy” will be the elements that will be stacked together. The CSS is where it’s important, you want to make sure the container width and the total element widths match. For example, if you want to have four columns of elements, each having a width + padding of 190px and a margin-right of 10px, then the container will be 200 x 4 = 800px:

New post from the Search Engine Roundtable: Someone “…received a response from Google to a reconsideration request that the only way his site will be reincluded in Google is if he removes all or most of the links in those WordPress themes.” The problem is that those links are in the form of sponsored links on footer (a practice I saw a lot in the past, not so much in the present).

I don’t think it will be easy, or even possible, to do what Google requested. If a theme contains an upgrade notification feature it might be possible to do, but even then the users might choose not to upgrade.

Secondly, if this is true, I wonder whether Google differentiates between credit links (“Designed by…”) and sponsored links. I would say they should, but then again I’m not a SEO guy.

Couple of days ago we got Starbucks’ style guide, and now here’s another by Google. I think the interesting thing is the rule to “\[o\]mit the protocol from embedded resources“. So instead of typing <script src="http://www.google.com/js/gweb/analytics/autotrack.js"></script>, they recommend to type <script src="//www.google.com/js/gweb/analytics/autotrack.js"></script> instead (without the http part). Never heard of that before.

Robb Shecter’s WordPress site got popular overnight thanks to Reddit and went down immediately. The interesting aspect is that the site was new and it’s on a relatively high-powered server. The author then found that the theme he used in particular was doing too many (47!) server requests at a time, and the site ran along very well after switching back to Twenty Eleven.

I’ve always been on the hunt for that perfect syntax highlighter plugin. Currently I’m using WP-Syntax, which does its job very well. However I’ve just found this plugin called Crayon Syntax Highlighter, which could be a good contender for the best WordPress syntax highlighter plugin out there.

The Starbuck website has its own style guide, accessible for public. I think its a neat idea, wouldn’t it be cool if themes have their own style guide? Pretty sure it will be helpful both to users or developers alike, if time consuming to write.

Also, I wonder what they use for the various toggles panel on the top right corner like on this page. It shows background, baseline, boxes, can be used to change windows size as well. Looks like it’s custom coded, imagine how super useful it can be if it’s a jQuery plugin.

I love theme options frameworks. And I want you guys to check this new framework called NHP. It passes my “does its UI look like the rest of WordPress enough?” test (screenshots here), it has tons of field types, and even offer validations, too.

Can’t wait to test and probably use it too in my to-be-released theme hint hint

Based on the comments, it appears that a lot of people agree with this list. Some of the items mentioned can be achieved with plugins (e.g Tax Meta Class to add meta data to taxonomy items, Custom Post Types Relationships for, well, creating custom post type relationships), so expect there to be a bunch of debates about what should and shouldn’t go to the core.

I like his list, but I disagree with his assessment that we don’t need new core themes. We do, especially to bring about the standard for how a theme options should be designed. This is the aspect that desperately needs to be standardized. Different theme companies and individual theme designers have their own idea of how the theme option UI should look, and it’s hurting the users.

I think the next big opportunity is around agencies and consulting—there will be five to six companies as large as Automattic, just providing high-end consulting and services to the large customers who are adopting WordPress en masse.

The one issue with creating responsive web design is in displaying images, especially getting the most appropriate size in a particular screen size. One solution for it is the Responsive-Enhance jQuery plugin. It works by loading small-sized images by default, then checks the screen size and loads the bigger version if necessary.

According to its creator, Josh Emerson:

This results in a faster perceived page load speed, but a slower actual speed. I’m happy with this solution as I care more about perceived speed than actual speed.

This tutorial by Keir Whitaker takes the whole thing further by teaching us how to apply Responsive-Enhance in WordPress.

A little peek under the hood shows that the site now uses a Twenty Ten child theme called “WordCamp Central 2012″. The site uses a plugin called WP Event Ticketing for ticketing purposes, and WP Super Cache for speed.