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

[melchoyce]

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

[paulwilde]

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

[DrewAPicture]

#29809 was marked as a duplicate.

[afercia]

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' :(

[afercia]

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

[melchoyce]

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.

[paulwilde]

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]

Remove accidental CSS change.

[dd32]

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.

[afercia]

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.

[afercia]

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.

[swissspidy]

See ​#meta1714

[melchoyce]

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

[swissspidy]

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.

[danieltj]

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]

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.

[afercia]

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

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:

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

[danieltj]

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?

[swissspidy]

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:

[pento]

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.

[pento]

Replying to pento:

I'll see how the SVG is generated.

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

[pento]

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.

[afercia]

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

[swissspidy]

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

[pento]

In 30186.2.diff​:

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

[pento]

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

[obenland]

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]

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.

[pento]

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

[pento]

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.

[Travel_girl]

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

[johnbillion]

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]

Screenshot of icons on Plugins screen on a mobile device

[melchoyce]

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?

[joemcgill]

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

[melchoyce]

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]

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.

[afercia]

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

[pento]

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

[melchoyce]

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

[pento]

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.