Improve layout of Appearance > Header with flexible-height headers added

[mbijon]

Support for flexible-height header images was added in #17242. In that ticket @aaroncampbell suggested we use Masonry to improve the layout of the Headers layout, http://core.trac.wordpress.org/ticket/17242#comment:63.

His patch applying Masonry to that page was then added in [20060], but @nacin found a bugs where the header images would overlap when Masonry was enabled, http://core.trac.wordpress.org/ticket/17242#comment:68. Masonry was then disabled in [20206] and removed entirely in [20340].

This ticket is to reintroduce Aaron's patch with Masonry, http://core.trac.wordpress.org/attachment/ticket/17242/17242.masonry.2.diff, and debug the overlapping images @nacin found. Or, create a different method for doing the same thing.

I worked up a new patch that's consistent with the current version of trunk AND should account for images. Take a look.

This quite obviously requires the Masonry JS files to be put into wp-includes/js. Wasn't sure how to account for that in the .diff.

Version number indicates when the enhancement was initially suggested.

Whoops. Pass #2 -- let's move the Masonry enqueueing inside of the if().

This doesn't look any different from [20060] except that we're actually waiting until DOM ready this time. If that was our original problem, d'oh.

That and the fact that Masonry freaks out if you don't wrap images in a call to imagesLoaded.

I was going to say that we should move that code into custom-header.js and make masonry a dependency, but we don't have a custom-header.js. wp_enqueue_script('custom-header') is fairly useless, in that case. :-)

Replying to nacin:

I was going to say that we should move that code into custom-header.js and make masonry a dependency, but we don't have a custom-header.js.

We will in #20855 :)

Looks to me like the enqueueing in [20060] looks better than masonry2.diff​. I don't remember what step 3 is, but masonry should be enqueued even when the theme doesn't support header-text, right?

We should combine the approach in [20060] with the corrections in masonry2.diff​.

20346.patch​ introduces custom-header.js (also useful for #20855) and adds Masonry as a dependency. Left out the 'columnWidth: 230' part, seems better without it.

Two notes:
1) Yes, it looks better without the columnWidth. I think I had that in as a legacy concern before I started messing with the imagesLoaded functionality.

2) I only enqueued it for custom headers since that's the only place it gets called and, well, efficiency?

Crap. Not sure why it moved the version. Reverting.

Replying to zamoose:

2) I only enqueued it for custom headers since that's the only place it gets called and, well, efficiency?

I was referring specifically to the fact that it was in a current_theme_supports( 'custom-header', 'header-text' ) block. I assumed the 'header-text' part was simply missed, but wanted to be sure of the intent.

I'm game for 20346.patch​ — does need an enqueue, though.

Replying to nacin:

I'm game for 20346.patch​ — does need an enqueue, though.

custom-header.js is already enqueued in js_includes():
http://core.trac.wordpress.org/browser/tags/3.4.2/wp-admin/custom-header.php#L173

What needs done here? Do I need to issue a refresh?

Refreshed after [22030]

Awesome.

In [22228]:

jQuery Masonry for uploaded custom headers. props zamoose. fixes #20346.

In 22504:

Custom Headers: Ensure the ready event fires before fetching the existing headers to apply jQuery.masonry. see #20346, #21820.