Make WordPress Core

Opened 9 years ago

Closed 6 years ago

#30186 closed enhancement (fixed)

Add plugin icons to plugin list table in update-core.php

Reported by: melchoyce's profile melchoyce Owned by: pento's profile pento
Milestone: 4.9 Priority: normal
Severity: normal Version:
Component: Plugins Keywords: has-screenshots ui-feedback has-patch
Focuses: ui, administration Cc:

Description

Adding the icons to the list table would mirror the themes below. See attached (very rough) mockup.

Attachments (16)

plugin-list-icons.png (291.5 KB) - added by melchoyce 9 years ago.
30186.patch (2.6 KB) - added by afercia 8 years ago.
30186-plugins.php.diff (3.0 KB) - added by paulwilde 8 years ago.
plugins-thumbnails.png (379.8 KB) - added by paulwilde 8 years ago.
30186-plugins.diff (2.6 KB) - added by paulwilde 8 years ago.
Remove accidental CSS change.
30186.diff (2.8 KB) - added by pento 6 years ago.
30186.2.diff (3.0 KB) - added by pento 6 years ago.
30186.3.diff (3.0 KB) - added by pento 6 years ago.
30186.4.diff (3.3 KB) - added by obenland 6 years ago.
blue.png (393.0 KB) - added by Travel_girl 6 years ago.
Dark.png (392.0 KB) - added by Travel_girl 6 years ago.
white.png (392.4 KB) - added by Travel_girl 6 years ago.
Variations.png (8.3 KB) - added by Travel_girl 6 years ago.
trunk.wp-wp-admin-plugins.php.png (132.1 KB) - added by johnbillion 6 years ago.
Screenshot of icons on Plugins screen on a mobile device
plugin-icon-styles.png (96.8 KB) - added by melchoyce 6 years ago.
30186.5.diff (2.8 KB) - added by pento 6 years ago.

Change History (62)

#1 @paulwilde
9 years ago

This would also be nice inside the actual Installed Plugin list also, and just add a checkbox option to toggle the icons on/off.

#2 @DrewAPicture
8 years ago

#29809 was marked as a duplicate.

@afercia
8 years ago

#3 @afercia
8 years ago

  • Keywords has-patch has-screenshots added

First pass :) A couple of things so far:

  • The plugin icons returned by the API are squared. This would be slightly inconsistent with the Theme thumbnails which are rectangular.
  • The theme "thumbnails" are the full screenshots provided by the theme, generally 880x660 sometimes even larger (for example for Twenty Sixteen is 1200x900) and then forced to width='85' height='64' :(

https://cldup.com/7RAWe6537V.png

#4 @afercia
8 years ago

  • Milestone changed from Awaiting Review to 4.5
  • Owner set to afercia
  • Status changed from new to assigned
  • Version set to 4.4

#5 @afercia
8 years ago

About Plugins, was thinking that maybe there should be some fallback for plugins hosted elsewhere, with custom update handlers. Thoughts?

This ticket was mentioned in Slack in #design by afercia. View the logs.


8 years ago

#7 follow-up: @melchoyce
8 years ago

Note: these screens are also being worked on in Shiny Updates right now, but I think we should keep this ticket open until it gets merged.

#8 @paulwilde
8 years ago

I've thrown together a patch which also implements these on plugins.php, should that also be something to consider.

A couple of observations:

  • You have to include wp-admin/includes/plugin-install.php just to get access to the plugins_api function. There's a few other places that also are doing this just to get access to it. It feels dirty. Maybe it would be worth moving that function to a more global file?
  • I've pulled the if statements which sets $plugin_icon_url from wp-admin/includes/class-wp-plugins-list-install.php. This seems to be lacking from afercia's patch, so it wouldn't give priority to the SVG, and wouldn't include the fallback. Maybe this could be put into a helper function so it be used in 3 places? Or maybe the API could output this instead as a new key within the icons key?

@paulwilde
8 years ago

Remove accidental CSS change.

#9 follow-up: @dd32
8 years ago

Using plugins_api() calls inline is a no-go going forward, It's just not viable given the time it takes those calls to complete (a minimum of 600ms per call for sites hosted in Australia or Europe).

We could either cache it, or have the data available via the update check API (which is the route we'd probably take).

For development and iterations, please feel free to use inline calls, just know it'll need some WordPress.org work to switch it prior to it being released.

#10 in reply to: ↑ 9 @afercia
8 years ago

Replying to dd32:

We could either cache it, or have the data available via the update check API (which is the route we'd probably take).

Thanks @dd32, yep I see something changed in [36182] so this approach won't work anymore. Guess it applies also to the Updates screen redesign proposal in the ongoing development of Shiny Updates.

#11 in reply to: ↑ 7 @afercia
8 years ago

  • Milestone changed from 4.5 to Future Release
  • Owner afercia deleted

Replying to melchoyce:

I think we should keep this ticket open until it gets merged.

Definitely agree, thinking we should move it out from the 4.5 release report though. Feel free to put it back and re-assign it if still relevant.

#12 @obenland
8 years ago

  • Keywords shiny-updates added

#14 @melchoyce
7 years ago

Where'd this end up, post-Shiny Updates?

#15 @swissspidy
7 years ago

I don't know how stable it is, but the new plugin directory has some shiny REST API endpoints that contain icons. Only for single requests though it seems, e.g. https://wordpress.org/plugins/wp-json/plugins/v1/plugin/akismet

Might have to nudge meta team once again for this one.

#16 @danieltj
7 years ago

  • Keywords needs-refresh added

I was thinking about doing this as a plugin recently. Glad this has a ticket because it'd make plugins stand out easily within the admin area. Whilst it might be a bit of an ask, this could make it into 4.9 if we're quick enough.

@pento
6 years ago

#17 @pento
6 years ago

  • Keywords needs-testing added; needs-refresh removed
  • Milestone changed from Future Release to 4.9

In 30186.diff:

  • Make use of the data coming from the plugin update API (see #meta1714).
  • Add icons to plugin list table and plugin update table.

#18 follow-up: @afercia
6 years ago

Quickly testing latest patch, I'm not sure this should happen in the plugin list table, see below:

https://cldup.com/VthxTod_0J.png

when plugins have no icon, the readability suffers. Ideally, text should be aligned but in the plugin list table I'm wondering if there should be icons in the first place.

In the plugin update table:

https://cldup.com/6jEV1yot-B.png

When plugins have no icon consider to align text or maybe use a generic fallback icon.

#19 in reply to: ↑ 18 @danieltj
6 years ago

Replying to afercia:

[...]

when plugins have no icon, the readability suffers. Ideally, text should be aligned but in the plugin list table I'm wondering if there should be icons in the first place.

[...]

When plugins have no icon consider to align text or maybe use a generic fallback icon.

I'd suggest using a temporary/default icon generated for the plugin to be listed there instead. I'm surprised no icon is shown if there isn't one explicitly stated for the plugin. It should mimic the plugin directory and just show something.

I haven't tested the patch, but is there the ability to turn the plugin images off via Screen Options? I take it this isn't being included in 4.9, no?

#20 @swissspidy
6 years ago

I'd suggest using a temporary/default icon generated for the plugin to be listed there instead. I'm surprised no icon is shown if there isn't one explicitly stated for the plugin. It should mimic the plugin directory and just show something.

Yeah, the update API needs to send back default icons in that case, just like the regular plugins API. Just left a comment on the meta ticket as well.

I haven't tested the patch, but is there the ability to turn the plugin images off via Screen Options? I take it this isn't being included in 4.9, no?

I don't think there should be such an option. It's such a small addition and doesn't take much space.


Just tested 30186.diff and it looks like this:

https://cldup.com/BSvE6D8D5M.png

#21 follow-up: @pento
6 years ago

The plugin directory can't return a default icon, there's no file to refer to. The randomly generated icons you see are inline in the w.org HTML.

I agree that there should be a default icon, though. I'll see how the SVG is generated.

#22 in reply to: ↑ 21 @pento
6 years ago

Replying to pento:

I'll see how the SVG is generated.

Oh, it uses GeoPattern. We're not going to put that into Core. 🙂

#23 @pento
6 years ago

As mentioned on #meta1714, the GeoPattern code doesn't like being loaded outside of the context of the plugin directory code. If someone more familiar with that code can glue it together, we can use that for plugins hosted on w.org.

Either way, we'll still need a local fallback for non-w.org plugins.

#24 @afercia
6 years ago

Rather than adding a local image, I'd propose to consider building something with just CSS and maybe a dashicon. I'd like to see WordPress completely image-free one day :)

#25 @swissspidy
6 years ago

There's dashicons-admin-plugins we could use.

@pento
6 years ago

#26 @pento
6 years ago

In 30186.2.diff:

  • Add a default icon.
  • Fix them layout bugs.

@pento
6 years ago

#27 @pento
6 years ago

30186.3.diff removes whitespace around the plugin name that caused the Delete Plugin confirmation popup to look all janky.

#28 follow-up: @obenland
6 years ago

In class-wp-plugins-list-table.php, since variables are not mixed with strings anymore, could the td attribute style be swapped from single quote to the usual double quote?

Is there a reason you using esc_attr() rather than esc_url() for the icon src?

@obenland
6 years ago

#29 @obenland
6 years ago

In 30186.4.diff:

  • Switched ID selectors to using classes for easier override.
  • Added to padding-right on .plugin title to account of icon padding and existing title padding.
  • Exempted theme screenshots from being forced into 64x64 dimension on update-core.
  • Merged plugin icon margin and theme screenshot padding to not compound for theme screenshots.
  • Uses double quotes for td attributes in plugin list table.

#30 in reply to: ↑ 28 @pento
6 years ago

Replying to obenland:

Is there a reason you using esc_attr() rather than esc_url() for the icon src?

Nope, I think I just didn't change it from 30186-plugins.diff.

#31 @pento
6 years ago

  • Owner set to pento
  • Status changed from assigned to accepted

#32 @pento
6 years ago

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

In 41695:

Plugins: Add plugin icons to the plugin list tables.

To mirror theme list table behaviour, the plugin icon now appears next to plugins in the plugin list tables. For plugins that don't have an icon, or non-W.org plugins, a fallback dashicon is shown.

Props melchoyce, afercia, paulwilde, pento, obenland.
Fixes #30186.

This ticket was mentioned in Slack in #design by afercia. View the logs.


6 years ago

@Travel_girl
6 years ago

@Travel_girl
6 years ago

@Travel_girl
6 years ago

#34 @Travel_girl
6 years ago

I made some mockups for the default icon. My personal favorite would be the white icon on dark grey background.

#35 @johnbillion
6 years ago

  • Component changed from Upgrade/Install to Plugins
  • Keywords needs-patch added; has-patch shiny-updates needs-testing removed
  • Resolution fixed deleted
  • Status changed from closed to reopened
  • Version 4.4 deleted

This needs some more work.

  • The fallback icon is very stark. On a Plugins screen with few plugins from w.org, the fallback icons are really in your face. The fallback ison should be smaller, or have less contrast, or should be blank.
  • The icons cause layout issues and consume valuable screen real estate on mobile devices.
  • I'm not the biggest fan of loading yet more assets from a third party host (s.w.org) but I guess that boat has sailed. The icons are ballooning my Plugins screen by nearly 1 MB though.

@johnbillion
6 years ago

Screenshot of icons on Plugins screen on a mobile device

#36 @johnbillion
6 years ago

  • Keywords ui-feedback added

#37 @melchoyce
6 years ago

Mocked up alternate styles for the fallback icons in plugin-icon-styles.png:

.plugins .plugin-title .dashicons:before {
    padding: 2px;
    font-size: 60px;
}

.plugins .inactive .plugin-title .dashicons:before {
    background-color: #eee;
    box-shadow: inset 0 0 10px rgba(160,165,170,.15);
    color: #B4B9BE;
}

.plugins .active .plugin-title .dashicons:before {
    background-color: #e5f5fa;
    box-shadow: inset 0 0 10px rgba(191,231,243,.5);
    color: #33B3DB;
}

@joemcgill Do you know if there's a better way to compress these plugin icons?

#38 @joemcgill
6 years ago

@melchoyce Since it looks like these files are being served from the w.org servers some server side optimizations could be applied (if they're not already). Addy Osmani recently published a good overview of options at https://images.guide/. Otherwise, we're at the mercy of whatever the plugin author has uploaded, I presume.

It also looks like we generally have both a 128px and 256px version of those plugin icons, so maybe we can use the smaller one?

This ticket was mentioned in Slack in #design by afercia. View the logs.


6 years ago

#40 @melchoyce
6 years ago

Thanks @joemcgill :)

@pento We've been chatting about this in #design (here's a good starting point: https://wordpress.slack.com/archives/C02S78ZAL/p1507061200000530)

Consensus seems to be:

  • Let's start off with only loading plugin icons on the updates screen, per the original scope of the ticket. That should also mitigate some of the performance concerns, since in most cases you (hopefully) won't be updating every plugin on your site at one time.
  • Since we won't have active/inactive on the updates screen, let's use the grey styles:
.plugins .plugin-title .dashicons:before {
    padding: 2px;
    background-color: #eee;
    box-shadow: inset 0 0 10px rgba(160,165,170,.15);
    font-size: 60px;
    color: #B4B9BE;
}

@pento
6 years ago

#41 @pento
6 years ago

  • Keywords has-patch added; needs-patch removed

In 30186.5.diff:

  • Remove icons from the plugin list table, only show them on the updates screen.
  • Favour the 128x128 icon over the 256x256 icon, if the API returns both.
  • Apply fallback icon styling from @melchoyce.

Note: The w.org API returns four icons: default, svg, 2x, and 1x.

svg, 2x, and 1x are only defined if the plugin has those icons uploaded, default will be set to the first of svg, 2x, or 1x that is defined.

So, by using default in [41695], svg is the preferred icon, but it's falling back to 2x, by virtue of how the w.org API decides preference. 30186.5.diff explicitly defines the preference order for the updates screen plugin list as: svg, 1x, 2x, then default.

#42 @afercia
6 years ago

@pento quick question:
is there a way for plugins not hosted on the w.org repo to override the API response and provide their own icons?

#43 @pento
6 years ago

Yup, same as you can override the API response to provide updates for your plugin.

#44 @melchoyce
6 years ago

FYI when this gets committed, let's be sure to include props for the following folks who mocked up ideas, suggested improvements, and gave feedback in Slack:

  • @Travel_girl
  • @danieltj
  • @afercia
  • @karmatosed
  • @hugobaeta
  • @empireoflight
  • @brentjett

Was a great group effort :)

This ticket was mentioned in Slack in #core by melchoyce. View the logs.


6 years ago

#46 @pento
6 years ago

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

In 41755:

Plugins: Tweak the plugin icons added in [41695].

  • Remove plugins icons from the plugin list table, as there were performance issues loading the icons when the site had lots of plugins.
  • Depending on which icons the plugin has uploaded, prefer them in this order: svg, 128x128, 256x256.
  • Improve the style of the fallback icon for plugins that don't have an icon defined.

Props Travel_girl, danieltj, afercia, karmatosed,hugobaeta, empireoflight, brentjett, melchoyce, pento.
Fixes #30186.

Note: See TracTickets for help on using tickets.