I wrote an article for WPBegginer about how to use Masonry in a theme. In it I recommended deregistering WordPress’ built-in Masonry, since it was an out of date version. WordPress 3.9 now includes a current version of Masonry, which means that step is no longer needed. That’s pretty cool on it’s own, but it’s especially cool for me since I wrote the patch for updating it. That is one of the reasons why I am credited as a contributor in WordPress 3.9.

Enqueueing Masonry

Masonry version 3 introduced backwards-compatibility breaking changes to how it was configured. Masonry’s creator David DeSandro was awesome enough to create a shim that allows initialization scripts written for Masonry 3 to work with Masonry 2. The old handle for Masonry was ‘jquery-masonry’ that now enqueues the shim, while the new handle ‘masonry’ enqueues Masonry 3. If you’re initialization script is written for Masonry 3, you only need to enqueue ‘masonry’. If you’re initialization script was written for version 2, you enqueue, ‘jquery-masonry’ which automatically adds the full masonry script as well, since that is a dependency it is registered with. Example, using an initialization script written for Masonry 3:

add_action( 'wp_enqueue_scripts', 'slug_masonry' );
function slug_masonry( ) {
	wp_enqueue_script( 'masonry' );
	wp_enqueue_script( 'masonry-init', get_template_directory_uri().'/js/masonry-init.js', array( 'masonry' ), null, true );
}

Example, using an initialization script written for Masonry 2:

add_action( 'wp_enqueue_scripts', 'slug_masonry' );
function slug_masonry( ) {
	wp_enqueue_script( 'jquery-masonry' );
	wp_enqueue_script( 'masonry-init', get_template_directory_uri().'/js/masonry-init.js', array( 'masonry', 'jquery' ), null, true );
}

The ever so useful imagesLoaded is included with WordPress’ Masonry, so there is no need to enqueue it separately.