WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 2 years ago

#32005 closed defect (bug) (fixed)

Show longer strings in media dropdown

Reported by: pavelevap Owned by: pento
Milestone: 4.4 Priority: normal
Severity: normal Version: 4.1
Component: Media Keywords: has-patch needs-testing good-first-bug
Focuses: Cc:

Description

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.

Attachments (13)

Longer_strings_in_dropdown.png (30.2 KB) - added by pavelevap 3 years ago.
32005.diff (363 bytes) - added by wonderboymusic 2 years ago.
with100.png (143.5 KB) - added by AlbertoCT 2 years ago.
With 100% solution
without100.png (198.0 KB) - added by AlbertoCT 2 years ago.
Without 100% solution
32005-ar.patch (336 bytes) - added by aaronrutley 2 years ago.
32005-1.patch (547 bytes) - added by aaronrutley 2 years ago.
Screen Shot 2015-10-31 at 5.41.05 pm.png (222.0 KB) - added by aaronrutley 2 years ago.
32005-2.patch (873 bytes) - added by aaronrutley 2 years ago.
Screen Shot 2015-10-31 at 5.58.35 pm.png (235.9 KB) - added by aaronrutley 2 years ago.
Screen Shot 2015-11-01 at 1.38.24 PM.png (135.5 KB) - added by firewatch 2 years ago.
Patch 32005-2 looks good in Chrome 46 on OS X 10.10.
32005-3.patch (1.5 KB) - added by aaronrutley 2 years ago.
32005-4.patch (1.5 KB) - added by aaronrutley 2 years ago.
32005-5.patch (1.5 KB) - added by aaronrutley 2 years ago.

Download all attachments as: .zip

Change History (34)

#1 @helen
3 years ago

  • Version changed from trunk to 4.1

@wonderboymusic
2 years ago

#2 @wonderboymusic
2 years ago

  • Keywords has-patch needs-testing good-first-bug added
  • Milestone changed from Awaiting Review to 4.4

needs to be tested in all browsers

#3 @shedonist
2 years ago

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.

#4 @AlbertoCT
2 years ago

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
2 years ago

With 100% solution

@AlbertoCT
2 years ago

Without 100% solution

#5 @aaronrutley
2 years ago

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

Last edited 2 years ago by aaronrutley (previous) (diff)

#6 @AlbertoCT
2 years ago

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

#7 @pento
2 years ago

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

#8 @aaronrutley
2 years ago

@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
2 years ago

@aaronrutley
2 years ago

#9 @aaronrutley
2 years ago

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
2 years ago

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

#10 @pento
2 years ago

  • Owner set to pento
  • Resolution set to fixed
  • Status changed from new to closed

In 35499:

Media Library: Allow longer labels in the filter dropdowns.

Props aaronrutley, AlbertoCT.

Fixes #32005.

#11 @pento
2 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

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

https://cldup.com/mkMP8aHNGW.png

#12 @AlbertoCT
2 years ago

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?

Last edited 2 years ago by AlbertoCT (previous) (diff)

@aaronrutley
2 years ago

#13 @aaronrutley
2 years ago

@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.

#14 @ocean90
2 years ago

#34582 was marked as a duplicate.

#15 @pento
2 years ago

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
2 years ago

@aaronrutley
2 years ago

#16 @aaronrutley
2 years ago

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

#17 follow-up: @pento
2 years ago

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?

#18 in reply to: ↑ 17 @aaronrutley
2 years ago

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;

#19 @pento
2 years ago

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.

#20 @pento
2 years ago

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

#21 @pento
2 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

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.

Note: See TracTickets for help on using tickets.