Show longer strings in media dropdown

[pavelevap]

Continue from #30725.

Localized string is longer than English original and it is not visible the whole text. There is enough space to show the whole string... See attached screenshot.

[wonderboymusic]

needs to be tested in all browsers

[shedonist]

Using Windows 8.1, I tested patch https://core.trac.wordpress.org/attachment/ticket/32005/32005.diff in Firefox 41.0, Internet 11, and Safari 5.1.7, and Chrome 45 (Windows & Desktop mode) and it worked great.

[AlbertoCT]

I've tested patch 32005.diff using Windows 7 in Chrome 46 and it makes the 'Insert into post' button dissapear. See attached screenshots.

[AlbertoCT]

With 100% solution

[AlbertoCT]

Without 100% solution

[aaronrutley]

Using Chrome, I tested this patch.

The patch addresses the select box issue, however this patch causes the 'insert into post' button a the bottom of the media dialog to 'disappear'.

I've created a patch to address this by targeting the .attachments-browser .media-toolbar-secondary instead of just .media-toolbar-secondary

[AlbertoCT]

Patch 32005-ar tested on Chrome 46 and IE 11, works fine to me.

[pento]

Having a width bigger than max-width feels weird.

(Note for props purposes:o @AlbertoCT and @aaronrutley worked on this patch together at MEL contributor day.)

[aaronrutley]

@pento good point !

I looked into the history https://core.trac.wordpress.org/changeset/32121

As these two divs are floating, max-width by itself doesn't actually do anything.
This can be resolved by setting a width or setting display to inline block.

I've created another patch that sets the width (no longer max-width).

I've also set the search input to take up 100% of it's parent div,
this could be set to float:right but I figured it would be better to just make the search input bigger.

[aaronrutley]

I've just added another patch, this is also fixing the same underlying issue of max-width set in CSS (but not working).

This patch also addresses the original point of this ticket, there's now much more room for longer strings to be shown in the dropdown/select field.

[firewatch]

Patch 32005-2 looks good in Chrome 46 on OS X 10.10.

[pento]

In 35499:

Media Library: Allow longer labels in the filter dropdowns.

Props aaronrutley, AlbertoCT.

Fixes #32005.

[pento]

@afercia notes that this causes the header on /wp-admin/upload.php?mode=grid to be incorrectly aligned.

[AlbertoCT]

Ok I've checked this out and I'm really confused. The divs containing the filter selectors have totally different classes if selected in Grid or List mode. Even if esthetically they are identical. (Talking about /wp-admin/upload.php? here)

It doesn't make much sense that changing the css for post.php passes on to upload.php when the divs are considerably different. My guess is the solution is closer to change the selector for the recently changed css or something around that line.

EDIT: Being more specific, I think the better solution is having the same structure when selected in Grid or List mode, but I guess there is a good reason why it is coded like that?

[aaronrutley]

@afercia Thanks for spotting that bug!

@AlbertoCT Agreed, I'm assuming there's a good reason it's coded this way, we could look at refactoring this section as well at a later date.

@pento I've just submitted another patch (32005-3).
This has higher specificity to ensure these CSS changes only effect the .media-modal-content.

[ocean90]

#34582 was marked as a duplicate.

[pento]

With 32005-3.patch​ applied, the Insert into post button isn't at the far right of the bar like it used to be.

Everything else looks good so far.

[aaronrutley]

Thanks @pento, I've just created 32005-5.patch​ to fix that issue.

[pento]

It seems like there's some redundant float: rights happening.

If we remove the width from .media-modal-content .media-toolbar-primary.search-form, then the float: right in .media-modal-content .media-toolbar-primary .media-button becomes unnecessary, I think. Is there another reason for that width to exist?

[aaronrutley]

Replying to pento:

It seems like there's some redundant float: rights happening.

If we remove the width from .media-modal-content .media-toolbar-primary.search-form, then the float: right in .media-modal-content .media-toolbar-primary .media-button becomes unnecessary, I think. Is there another reason for that width to exist?

We want the div for .search-form at the top of the modal to have a width of 33%.
If we take that off the search input field doesn't fill the space.

For some reason the div the .media-buttons are sitting in a div with the class of .search-form
If we remove that class we won't need to force the buttons to float:right;

[pento]

Ah, I see. Given that there doesn't seem to be any other CSS being applied to that div because of the search-form class, I'm inclined to remove it, so we can clean up a little bit of the CSS.

[pento]

On further reflection, the Backbone Toolbar view really doesn't lend itself to conditionally removing the search-form class.

[pento]

In 35532:

Media Library: After [35499], increase the specificity of our selectors so that they don't cause problems for the wp-admin Media Library page.

Props aaronrutley.

Fixes #32005.