WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 4 years ago

Last modified 3 years ago

#26952 closed task (blessed) (fixed)

Style TinyMCE modals to match WordPress admin styling

Reported by: melchoyce Owned by: helen
Milestone: 3.9 Priority: normal
Severity: normal Version: 3.9
Component: TinyMCE Keywords: has-patch commit dev-reviewed
Focuses: ui Cc:

Description

There are a couple instances of TinyMCE modals which don't visually match the rest of the admin:

https://i.cloudup.com/7UHFeLt0VI.png

https://i.cloudup.com/ZGnfapAkcq.png

Let's restyle them to match.

Attachments (36)

mce-4.0-less-sources.zip (52.5 KB) - added by azaozz 4 years ago.
skin.min.css (37.4 KB) - added by azaozz 4 years ago.
Non-minified compiled stylesheet
plugin-install-media-modal-UI.png (439.2 KB) - added by paulwilde 4 years ago.
Screen Shot 2014-01-31 at 11.46.36 PM.png (48.8 KB) - added by helen 4 years ago.
Media attach dialog
tinymce-help-modal.jpg (303.3 KB) - added by melchoyce 4 years ago.
tinymce-char-modal.jpg (245.7 KB) - added by melchoyce 4 years ago.
screen-shot-2014-02-13-at-9-58-30-am.png (17.6 KB) - added by melchoyce 4 years ago.
26952.patch (17.9 KB) - added by iseulde 4 years ago.
26952.2.patch (820 bytes) - added by iseulde 4 years ago.
tinymce-modal-dropdown-bug.png (54.0 KB) - added by alleynoah 4 years ago.
dropdown menu hidden behind the modal
26952.modal-menu-override.patch (278 bytes) - added by alleynoah 4 years ago.
add z-index override to modal dropdowns also
26952.3.patch (7.6 KB) - added by iseulde 4 years ago.
Screen Shot 2014-03-04 at 15.46.06.png (171.3 KB) - added by iseulde 4 years ago.
26952.4.patch (7.3 KB) - added by iseulde 4 years ago.
26952.5.patch (24.5 KB) - added by iseulde 4 years ago.
26952.6.patch (24.7 KB) - added by iseulde 4 years ago.
Screen Shot 2014-03-05 at 14.31.43.png (108.8 KB) - added by iseulde 4 years ago.
Screen Shot 2014-03-05 at 14.31.06.png (142.8 KB) - added by iseulde 4 years ago.
Screen Shot 2014-03-07 at 22.51.17.png (39.0 KB) - added by iseulde 4 years ago.
26952.7.patch (40.3 KB) - added by iseulde 4 years ago.
wplink.png (47.2 KB) - added by azaozz 4 years ago.
26952.8.patch (39.5 KB) - added by azaozz 4 years ago.
26952.9.patch (39.4 KB) - added by iseulde 4 years ago.
26952.10.patch (1.1 KB) - added by azaozz 4 years ago.
26952.11.patch (13.4 KB) - added by iseulde 4 years ago.
Screen Shot 2014-03-13 at 22.25.04.png (26.6 KB) - added by iseulde 4 years ago.
26952.12.patch (15.1 KB) - added by iseulde 4 years ago.
26952.13.patch (13.3 KB) - added by iseulde 4 years ago.
Screen Shot 2014-03-14 at 15.46.43.png (213.3 KB) - added by iseulde 4 years ago.
26952.diff (1.4 KB) - added by paulwilde 4 years ago.
26952.14.patch (2.0 KB) - added by iseulde 4 years ago.
26952.15.patch (3.8 KB) - added by iseulde 4 years ago.
26952.16.patch (3.8 KB) - added by iseulde 4 years ago.
26952.17.patch (1.5 KB) - added by ocean90 4 years ago.
before.importer.png (91.6 KB) - added by ocean90 4 years ago.
after.importer.png (103.4 KB) - added by ocean90 4 years ago.

Change History (138)

This ticket was mentioned in IRC in #wordpress-ui by melchoyce. View the logs.


4 years ago

#2 @nacin
4 years ago

  • Milestone changed from Awaiting Review to 3.9

@azaozz
4 years ago

Non-minified compiled stylesheet

This ticket was mentioned in IRC in #wordpress-dev by melchoyce. View the logs.


4 years ago

#4 follow-up: @melchoyce
4 years ago

Is the best way to restyle these modals to overwrite the default TinyMCE styles, or to remove the default TinyMCE styles and let them inherit styles/classes and from core?

#5 follow-up: @iseulde
4 years ago

What kind of styles do you have in mind for them? I'll have to do the same thing for the front-end.

#6 in reply to: ↑ 5 @melchoyce
4 years ago

Replying to avryl:

What kind of styles do you have in mind for them? I'll have to do the same thing for the front-end.

That's a good question.

We have, as far as I can tell (there might be more), three entirely different modal styles:

In this instance, I had the theme browser in mind as a general modal style as I think it'll be easy to design tabs into. That said, the media modal styles already have tabs we could use: https://cloudup.com/cmy9QpXCwrx.

This could be a good opportunity to establish one consistent core style we could use for all modals. What are your thoughts?

#7 @iseulde
4 years ago

+ 1 for having one design to rule them all. :)

#8 follow-up: @iseulde
4 years ago

I do like the media modal most, but it needs to be better designed for small screens. When you have a lot of menu items in the sidebar, it will cover too much on top, and the tabs are also a bit weird.

#9 in reply to: ↑ 8 @melchoyce
4 years ago

Replying to avryl:

I do like the media modal most, but it needs to be better designed for small screens. When you have a lot of menu items in the sidebar, it will cover too much on top, and the tabs are also a bit weird.

Agreed — though in the case of the TinyMCE modals, we'd drop the sidebar entirely.

#10 follow-ups: @iseulde
4 years ago

Sure, but it'd be good to make something reusable! :)
And you'll probably want smaller modals for that as well?

#11 in reply to: ↑ 10 @melchoyce
4 years ago

Replying to avryl:

Sure, but it'd be good to make something reusable! :)
And you'll probably want smaller modals for that as well?

True. And yeah, we'd want to scale down the size of each modal to something more proportionate to that modal's particular content.

#12 in reply to: ↑ 10 ; follow-up: @nacin
4 years ago

Replying to avryl:

Sure, but it'd be good to make something reusable! :)

The media modal is very flexible. The sidebar isn't required, and in fact media sometimes doesn't use it, depending on the task.

#13 in reply to: ↑ 12 @iseulde
4 years ago

Replying to nacin:

Replying to avryl:

Sure, but it'd be good to make something reusable! :)

The media modal is very flexible. The sidebar isn't required, and in fact media sometimes doesn't use it, depending on the task.

Yes, of course, I know! I just meant that we should reuse one modal design for everything, and adjust it to the needs. E.g. the current sidebar works great on small screens if there are only four items in it, but it breaks with more. Reuse it for smaller modals etc. It could be even more flexible.

#14 @paulwilde
4 years ago

Been following the discussions and thought I'd throw together a quick mockup of what the plugin installer modal could look like given WordPress were to have a single consistent modal UI as suggested. Apologises that it's unrelated to TinyMCE and therefore could sit in its own ticket. Just wanted to get some ideas flowing and to add some context to the discussion. :)

Last edited 4 years ago by paulwilde (previous) (diff)

#15 @iseulde
4 years ago

Looks very nice!

#16 @melchoyce
4 years ago

That looks awesome — it works great with the plugin content!

#17 in reply to: ↑ 4 @azaozz
4 years ago

Replying to melchoyce:

Is the best way to restyle these modals to overwrite the default TinyMCE styles, or to remove the default TinyMCE styles and let them inherit styles/classes and from core?

Currently the default is used for the toolbar buttons and partially overridden in editor.css. Thinking we can do the same for the modals.

Last edited 4 years ago by azaozz (previous) (diff)

#18 @nacin
4 years ago

It's worth noting that the plugin information tab used to look like the plugin directory page on WP.org, by design. (It was practically a mirror image). Over time, WP.org started to look more modern. This would in effect cause the dashboard to again leapfrog WP.org. I don't think that's a problem, but I did want to point it out.

Could we sneak in banner images? Does that work with the constraints? Just curious. :-)

#19 @azaozz
4 years ago

Don't see a reason why banner images wouldn't work, especially if the modal is a bit wider to reduce scrolling.

#20 @helen
4 years ago

How about reviews too, then? :) #22599

@helen
4 years ago

Media attach dialog

#21 @helen
4 years ago

Remembered another modal - the attach unattached media one. Screenshot uploaded above.

This ticket was mentioned in IRC in #wordpress-dev by nacin. View the logs.


4 years ago

#23 @melchoyce
4 years ago

Attached two modal mockups above.

Still to-do: the text formatting (paragraph, header, etc.) dropdown, the color dropdown, and the media attachment modal helen posted above.

Last edited 4 years ago by melchoyce (previous) (diff)

@iseulde
4 years ago

#24 @iseulde
4 years ago

First attempt:

  • Removes text-shadow from dashicons.
  • Removes weird border radius from Quicklinks toolbar.
  • Fixes arrow border and replaces arrow with dashicon.
  • Inherit colours and font (i.e. Open Sans).
  • Makes tooltip shadows lighter and font a bit bigger (11px ->12px).
  • Also adds some margin between the tooltip and buttons.
  • Restyles Charmap and Help modals.
  • Added cursor: pointer; to Charmap table cells.
  • Removed the close button from the Help modal, because the button will be too big when enqueuing button styles (iframe is small and triggers responsive styles) and I think it's cleaner like this anyway.
  • Restyles the format button (but I'm not sure if it's good enough). I think it'd be good if buttons with an arrow all have the same style though.
  • Flips the arrow when the menu is open.
  • Restyles the format and colour menus.

TODO

  • I'd be easier if the Help modal wasn't an iframe. Maybe remove it? Not sure if it's possible.
  • Style TinyMCE buttons (e.g. in the plain text modal). It's probably easiest to add button[type="button"]to buttons.css, though TinyMCE wraps it in a div and styles that. Not sure which solution is best and doesn't add too much CSS.
  • Test other TinyMCE plugins.
  • Test on the front-end (wp_editor).
Last edited 4 years ago by iseulde (previous) (diff)

#25 @iseulde
4 years ago

@melchoyce I'm not sure if it's possible to style the Charmap sidebar like in your mock up since TinyMCE doesn't provide any ids and styling it might affect other elements in other modals.

Last edited 4 years ago by iseulde (previous) (diff)

#26 @azaozz
4 years ago

In 27190:

TinyMCE: style the modals to match WordPress admin (first-run). Fix couple of IE problems in tiny_mce_popup.js. Props avryl, see #26952, see #24067

#27 @iseulde
4 years ago

@azaozz Okay, so is it better not to mimic the media modal style entirely for TinyMCE modals? I agree it's a bit hacky with the iframe...

@iseulde
4 years ago

#28 @iseulde
4 years ago

Looks like I didn't overwrite the font properly. I've also re-added the colours for the close button.

#29 @azaozz
4 years ago

In [27193]

TinyMCE: revert style for the blocks drop-down in the toolbar, limit the styles imported for the same drop-down, make the menu highlight color grey. Part props avryl, see #26952

#30 follow-up: @alleynoah
4 years ago

In changeset [27190], the use of !important in the modal's z-index styling (for example, https://core.trac.wordpress.org/browser/trunk/src/wp-includes/css/editor.css#L24) to override TinyMCE's use of inline z-index styling causes problems -- if there are additional modal elements, they appear behind the overridden modal and mask. This breaks some elements of the TinyMCE4 table plugin for example (I'll attach a screenshot below). I know it mirrors the media modal styles, but is it necessary to override the z-index this way? On my instance if I simply disabled those overrides I didn't notice any issues, but there certainly may be cases that I'm not thinking of.

I'll also attach a patch that solves the problem for me in the opposite direction (just by adding a similar override to the menu element). My concern about the "more overrides" direction is just that it could potentially mean adding overrides for every special case where TinyMCE already has the handling built, and might make using TinyMCE4 plugins more complex.

@alleynoah
4 years ago

dropdown menu hidden behind the modal

@alleynoah
4 years ago

add z-index override to modal dropdowns also

#31 in reply to: ↑ 30 ; follow-up: @azaozz
4 years ago

Replying to alleynoah:

...is it necessary to override the z-index this way?

Yes, unfortunately. Otherwise the modals are "under" the DFW. Thinking the best way to handle this would be to review/audit all z-index values in our css. A lot of them are needlessly high. This has caused problems several times before and the "solution" was to bump them even higher.

#32 in reply to: ↑ 31 @alleynoah
4 years ago

Replying to azaozz:

Yes, unfortunately. Otherwise the modals are "under" the DFW. Thinking the best way to handle this would be to review/audit all z-index values in our css. A lot of them are needlessly high. This has caused problems several times before and the "solution" was to bump them even higher.

Ah, that makes sense to me, thanks!

@iseulde
4 years ago

#33 @iseulde
4 years ago

26952.3.patch restyles the modal for attaching media to posts.
Before.

#34 @azaozz
4 years ago

In 27401:

Restyles the modal for attaching media to posts, props avryl, see #26952

#35 @iseulde
4 years ago

Whoops, I was just improving the patch. There's also a jshint error for an unused variable btw. Sorry, should test before uploading patches.

@iseulde
4 years ago

This ticket was mentioned in IRC in #wordpress-ui by avryl. View the logs.


4 years ago

#37 @azaozz
4 years ago

In [27403]:

Restyles the modal for attaching media to posts, take II (also some autoprefixer and imagemin). Props avryl, see #26952.

@iseulde
4 years ago

@iseulde
4 years ago

#38 @iseulde
4 years ago

26952.6.patch restyles the link modal in the editor. Instead of jQuery UI it's just CSS, and it also removes the redundant jQuery UI stylesheet. I did the toggling of the existent content search a bit differently. It becomes visible when you focus on the search field and hides again if you focus on one of the other fields. Let me know what you think.

#39 @SergeyBiryukov
4 years ago

#27310 was marked as a duplicate.

This ticket was mentioned in IRC in #wordpress-ui by helen. View the logs.


4 years ago

#41 @iseulde
4 years ago

Restyled jQuery UI dialog. When the link modal is done, this will no longer be used in core, but may be used by plugins.

#42 @azaozz
4 years ago

In 27460:

Set minimum z-index for the TinyMCE modals and adjust the z-index in DFW, see #26952

#43 @azaozz
4 years ago

In 27461:

Adjust .find-box-inside responsive style, props avryl, see #26952

@iseulde
4 years ago

#44 @iseulde
4 years ago

Voilà, last patch restyles the jQuery UI dialog (that plugins may use) and restyles the wplink modal with the current behaviour in mind (+ animation and responsive width/height).
Didn't test in IE, so it'd be great if someone could do that.

#45 @iseulde
4 years ago

Next: ThickBox. :)

@azaozz
4 years ago

#46 @azaozz
4 years ago

26952.7.patch works better. Still not sure about scrolling the whole "body" hiding the top part and then auto-scrolling to the top on clicking a search result in the bottom part. The old behavior is a better UX imho. Clicking on a search result fills the fields at the top, logically they should always be visible.

Also we lost the "Cancel" link and containing the "tabbing" inside the modal (will add that back). The "X" is not a "tab stop" either.

Was also looking at the search field. Currently it triggers AJAX request on typing 3 chars and on every character after.

  • 3 characters should be ok for most languages, but not for gliphs. The user may want to search on the first or second gliph.
  • Typing a 10 characters search string triggers 8 concurrent AJAX connections (8 POST requests, 8 DB connections, etc.). Seems pretty wasteful.

Thinking it would be better to have a Submit button for searching. Don't remember if there was one at first, but there is definitely space for it.

Not so sure about the changed "looks" too. Patched it looks like the left side of the above image, was thinking it should be more like the right one. We would change the structural CSS, the header, and tweak the colors in the modal's "body". Not sure it needs anything else.

The "header" and "footer" feel very large too, especially when the modal is folded. I realize we are trying to follow the media modal styling but it covers nearly the whole screen and the footer there has another purpose (shows thumbnails). In all the rest of the modals the footer only holds the "submit" button.

Last edited 4 years ago by azaozz (previous) (diff)

#47 @azaozz
4 years ago

In 27485:

Adjust the height of the header and footer in the Find Posts modal on the Media Library screen, see #26952

@azaozz
4 years ago

#48 @azaozz
4 years ago

26952.8.patch uses parts of 26952.7.patch but attempts to keep the look the same/similar to the current modal. It also auto-shows the internal links part on screens < 768px wide or < 440px high. Still needs some cleanup and tabbing fixes.

#49 @iseulde
4 years ago

Still not sure about scrolling the whole "body" hiding the top part and then auto-scrolling to the top on clicking a search result in the bottom part. The old behavior is a better UX imho. Clicking on a search result fills the fields at the top, logically they should always be visible.

I thought it would be better to allow more space for the list depending on your screen size. But yes, it'd be better if the input fields are visible after selecting a post. Scrolling to the top would be annoying, so it looks like the old scroll behaviour is better.

Also we lost the "Cancel" link […]

I think we should get rid of it. No other modal has it.

Not so sure about the changed "looks" too. Patched it looks like the left side of the above image, was thinking it should be more like the right one. We would change the structural CSS, the header, and tweak the colors in the modal's "body". Not sure it needs anything else.
The "header" and "footer" feel very large too, especially when the modal is folded. I realize we are trying to follow the media modal styling but it covers nearly the whole screen and the footer there has another purpose (shows thumbnails). In all the rest of the modals the footer only holds the "submit" button.

I agree that the headers look a bit big (was trying to copy it from the media modal). So let’s resize them to about 40px? I’d keep the colour of the header though, and remove the visual distinction of the footer.

@iseulde
4 years ago

#50 @iseulde
4 years ago

Last patch just adds some space between the query results and the footer, removes the border from the last list item and removes the 11px font-size of the checkbox label. Not sure why that was 11px.

#51 @iseulde
4 years ago

I also noticed that the link modal and TinyMCE modals are the only modals that currently don't close when you click on the backdrop. Not difficult to add to the link modal, maybe be worth asking Spocke to add this to the TinyMCE modals?

#52 @azaozz
4 years ago

In 27494:

wpLink: stop using UI dialog, restyle the modal, add better responsive behaviour.
Fix UI dialog styling to match the rest of the admin styling.
Props avryl, see #26952

#53 follow-up: @nacin
4 years ago

[27494] results in a super-tall modal when the post list is expanded. When collapsed, it's shoved up to the top of the page, rather than being vertically centered. Neither of these are ideal. It should be relatively short and centered on the page.

Why the move away from jQuery UI dialog? It worked fine, and it also enabled you to actually move the dialog around, which was helpful if you wanted to glance at your post again while inserting a link. (I happen to do this a lot.)

Generally speaking, we should shrink the size of the titles in these modals. The media modal is fine to have a large title because it takes up the entire screen. But special characters, about, shortcuts, and links don't; it overpowers the screen.

#54 @nacin
4 years ago

I would like a cancel link back. The link dialog went through like 50 rounds of UI iteration and a boatload of user tests, every aspect of it was very carefully designed.

#55 in reply to: ↑ 53 @iseulde
4 years ago

Why the move away from jQuery UI dialog?

The problem with the jQuery UI dialog is that it's not responsive.
attachment:26952.7.patch added an animation just like the old modal. The collapsed modal would be vertically centred and expand smoothly.

Generally speaking, we should shrink the size of the titles in these modals.

Sure, I agree. We should try to find a good balance. melchoyce? :)

I would like a cancel link back. The link dialog went through like 50 rounds of UI iteration and a boatload of user tests, every aspect of it was very carefully designed.

If we leave the cancel button in this dialog, we should add one to the others as well. The UI isn't consistent like this.

This ticket was mentioned in IRC in #wordpress-ui by avryl. View the logs.


4 years ago

#57 @azaozz
4 years ago

Yeah, perhaps we should have Cancel in all modals. Looking at the TinyMCE modals, all have it. How about we center it vertically with CSS's calc() (excludes IE8).

#58 @azaozz
4 years ago

In 27495:

wpLink: set max-height to 500px (like before) and vertically center the modal (except in IE8), see #26952

@azaozz
4 years ago

#59 @azaozz
4 years ago

Also reduced the modal title font size and height a bit in [27495]. In 26952.10.patch: bring back wpLink's Cancel button.

#60 @helen
4 years ago

We touched on this briefly in IRC the other day, but there are some concerns here about back-compat with people using the .wp-dialog class and anybody who's targeting things in the link modal.

#61 @nacin
4 years ago

  • Type changed from defect (bug) to task (blessed)

#62 @azaozz
4 years ago

In 27496:

wpLink: better structural and responsive styles, see #26952

#63 @azaozz
4 years ago

In 27510:

wpLink: bring back the Cancel link, improve responsive styles, see #26952

#64 @azaozz
4 years ago

In 27513:

TinyMCE modals: re-enable the Close button in charmap, fix arrows in listboxes, add and position dashicons to the menu (when visible), see #26952

#65 @bradyvercher
4 years ago

The old wpLink modal triggered a 'wpdialogbeforeOpen' event before opening. Can we get something similar with the new modal?

This ticket was mentioned in IRC in #wordpress-dev by azaozz. View the logs.


4 years ago

@iseulde
4 years ago

#67 @iseulde
4 years ago

Last patch darkens all the overlays, updates all the shadow, all the headings, styles thickbox a bit (heading should be 29px, because it's hardcoded...) and makes the link modal a bit smaller in width.
Stil to do: style the plugin modal (without thickbox).

#68 @iseulde
4 years ago

In the link modal, the button is not responsive. That's because there's no button class. The input fields also don't really wrap well. See screenshot above.

@iseulde
4 years ago

This ticket was mentioned in IRC in #wordpress-ui by avryl. View the logs.


4 years ago

#70 @azaozz
4 years ago

In 27532:

Modals: darken all overlays, update all box-shadows and headings, correct thickbox styling, make the link modal narrower and bring back the animation (css transition). Props avryl, see #26952

@iseulde
4 years ago

#71 @iseulde
4 years ago

Patch above restyles the plugin details modal. It still uses thickbox, and should be redone some other time (maybe with backbone and without frames?). Might be worth creating a separate ticket.
Props paulwilde for initial mockup.

#72 @iseulde
4 years ago

The 'warning' message is still a bit weird on a white backgrounds, and the tabs don't wrap well on small screens. But this is a bigger issue with tabs in core.

#73 @azaozz
4 years ago

In 27559:

Restyle the plugin install details modal to match the rest of the admin. Props avryl and paulwilde for initial mockup, see #26952

#74 @azaozz
4 years ago

Had to change couple of things in 26952.13.patch:

  • Moved the scrollbar from the middle of the modal to the right.
  • Reduced size of the header and footer to match the rest of the modals.

#75 @iseulde
4 years ago

Ah, melchoyce and I decided to use a bigger header since the size of the modal is significantly bigger. I'll take a look.

#76 @azaozz
4 years ago

Yes, was thinking this modal can actually cover the whole screen like the media modal. Then perhaps we could pull the plugin header image in it too (needs WordPress.org API update).

#77 follow-up: @iseulde
4 years ago

I would definitely make the heading bigger again. The modal is different because it's bigger, has tabs and looks a lot like the media modal with the side bar.
The line between the heading and the tabs doesn't look right. I think the sidebar also looks better covering the full height, just like the one in the media modal. What do you think, melchoyce?

We could put a lot more things in the modal, not just the image. E.g. the contributors and their avatars, the possibility to rate the plugin without visiting wp.org, reviews, submitting reviews, a 'This works for me' toggle', favourite, submit a support ticket etc. etc. But this is out of scope for this ticket and release. Shall I make a separate ticket? :)

Last edited 4 years ago by iseulde (previous) (diff)

#78 in reply to: ↑ 77 @azaozz
4 years ago

Replying to avryl:

I would definitely make the heading bigger again. The modal is different because it's bigger, has tabs and looks a lot like the media modal with the side bar.

Looks pretty similar in size to the "Find Posts or Pages" modal on the Media Library screen, and a lot smaller than the media modal. Especially on a (somewhat) standard 1080p desktop monitor. Don't mind either way though.

The line between the heading and the tabs doesn't look right.

Wouldn't that make it inconsistent compared to the other non-fullsize modals?

I think the sidebar also looks better covering the full height, just like the one in the media modal. What do you think, melchoyce?

Perhaps, but having a scrollbar in the middle of the modal and another one on the side just for the "sidebar" on smaller height is worse?

We could put a lot more things in the modal, not just the image. E.g. the contributors and their avatars, the possibility to rate the plugin without visiting wp.org, reviews, submitting reviews, a 'This works for me' toggle', favourite, submit a support ticket etc. etc. But this is out of scope for this ticket and release. Shall I make a separate ticket? :)

Yeah, sounds like a whole new project :)

#79 @paulwilde
4 years ago

Played about with the new Plugin modal design and agree with avryl's points.

I'm a bigger fan of the larger title with no seperator line. The seperator line gives off the impression that the contents of the modal isn't as tightly integrated to WordPress as it could be and that it comes from a third party site rather than WordPress itself. The contents of the modal flow better with no separation.

I'm also a fan of of the sidebar being fixed. When you scroll down you lose a lot of vital at-a-glance information about the plugin with nothing but whitespace replacing it, so you end up losing more than you gain. Adding height media queries could be used to prevent double scrollbars should that be an argument against the sidebar being fixed.

I've also noticed a slight regression caused by the new design. When you try and install a plugin you already have installed you are presented with a clickable action button labelled "Latest Version installed" which upon clicking does nothing. In the previous design you were unable to actually click this button. Adding a 'disabled' class to the link seems to fix it.

http://cl.ly/UTz1/disabled-state.png

Last edited 4 years ago by paulwilde (previous) (diff)

#80 @melchoyce
4 years ago

Just had a chance to preview. I also agree with all of avryl's points.

Wouldn't that make it inconsistent compared to the other non-fullsize modals?

Nope — it makes it consistent with the media modal. The same styling (removing the border) should be applied to the TinyMCE help modal as well. Any modal that contains tabs should not have an extra border between the tabs and the title.

#81 @paulwilde
4 years ago

I've gone ahead and created a new ticket for further enhancements to the Plugin modal at #27440 as to not entirely derail the ticket with out-of-scope ideas.

@paulwilde
4 years ago

#82 @paulwilde
4 years ago

Added a patch which fixes the disabled button behaviour I mentioned previously, along with making the dimensions of the loading spinner correct on HiDPI displays.

#83 @nacin
4 years ago

#27072 was marked as a duplicate.

This ticket was mentioned in IRC in #wordpress-ui by paulwilde. View the logs.


4 years ago

#85 @nacin
4 years ago

In 27677:

Plugin Installer: Disable 'Latest Version Installed' buttons.

props paulwilde.
see #26952.

#86 @nacin
4 years ago

In 27678:

Ensure Thickbox loading spinner is properly sized for HiDPI displays.

props paulwilde.
see #26952.

#87 follow-up: @nacin
4 years ago

What else is left here? I have the following:

  • I agree with melchoyce and avryl on the plugin info modal. Title needs to be bigger and border needs to be gone. This is more like the media modal than the link dialog.

Also, I like moving the scrollbar to the right on the plugin info modal. Could we still stick the "fyi" div to the top, if there's enough room for it to be presented? Like the sticky admin menu. If difficult/annoying to do, then it's not a big deal.

#88 in reply to: ↑ 87 @iseulde
4 years ago

Replying to nacin:

What else is left here? I have the following:

  • I agree with melchoyce and avryl on the plugin info modal. Title needs to be bigger and border needs to be gone. This is more like the media modal than the link dialog.

Also, I like moving the scrollbar to the right on the plugin info modal. Could we still stick the "fyi" div to the top, if there's enough room for it to be presented? Like the sticky admin menu. If difficult/annoying to do, then it's not a big deal.

Cool, I'll make a patch before the meeting. Not sure what you mean for the right sidebar. So leave it as it is now and and stick it on top if it's small enough? Or make it look like in the media modal (full height)?

@iseulde
4 years ago

#89 @iseulde
4 years ago

Let's also remove that line in the TinyMCE help modal and use the same tabs. I'll submit a patch asap.
Patch for the plugin modal above. Not sure if the sidebar is okay, but the chance that the content is longer than the height is pretty small. On small screens the sidebar is placed on top, and the aren't any screens that have a small height and long width.

@iseulde
4 years ago

#90 @iseulde
4 years ago

Last patch fixes the tabs in the help modal.

@iseulde
4 years ago

This ticket was mentioned in IRC in #wordpress-ui by helen. View the logs.


4 years ago

#92 @helen
4 years ago

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

In 27765:

Better, more consistent styling for plugin details Thickbox and TinyMCE help.

props avryl. fixes #26952.

This ticket was mentioned in IRC in #wordpress-dev by ipstenu. View the logs.


4 years ago

#94 @azaozz
4 years ago

In 27831:

Fix styling for mce-path (at the bottom of the editor), see #26952

#95 @nacin
4 years ago

In 27833:

Restore the original z-index of the sticky admin menu, as first set in [26442].

The inline comment is now correct again. This z-index was changed in [26701], but those circumstances no longer apply after [27532].

props mordauk.
see #26442, #26952.
fixes #26567.

#96 @ocean90
4 years ago

In 27932:

Fix styling for plugin update details Thickbox.

see #26952.

@ocean90
4 years ago

#97 @ocean90
4 years ago

  • Keywords has-patch commit added
  • Resolution fixed deleted
  • Status changed from closed to reopened

26952.17.patch does the same as [27932] but for the importer details Thickbox, see before.importer.png and after.importer.png.

#98 @azaozz
4 years ago

26952.17.patch looks good. Adds the thickbox CSS overrides to Tools -> Import.

#99 @nacin
4 years ago

  • Keywords dev-reviewed added

Good to go.

#100 @azaozz
4 years ago

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

In 28080:

Add the new modlas styling to the importer details Thickbox on Tools -> Import. Props ocean90, fixes #26952

#101 @iseulde
4 years ago

#22156 was marked as a duplicate.

This ticket was mentioned in IRC in #wordpress-dev by nacin. View the logs.


3 years ago

Note: See TracTickets for help on using tickets.