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.

[zamoose]

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

[zamoose]

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.

[SergeyBiryukov]

Version number indicates when the enhancement was initially suggested.

[zamoose]

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

[nacin]

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.

[zamoose]

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

[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. wp_enqueue_script('custom-header') is fairly useless, in that case. :-)

[SergeyBiryukov]

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 :)

[nacin]

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?

[nacin]

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

[SergeyBiryukov]

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.

[zamoose]

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?

[zamoose]

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

[nacin]

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.

[SergeyBiryukov]

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

[zamoose]

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

[SergeyBiryukov]

Refreshed after [22030]

[zamoose]

Awesome.

[nacin]

In [22228]:

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

[koopersmith]

In 22504:

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