WordPress 4.0 Adds Custom Icons to the Plugin Installer

The WordPress plugin installer page is about to get more colorful. The upcoming 4.0 release completely revamps the plugin search and installation process with plugin cards arranged in a new grid view. Andrew Nacin announced today that plugins will also have their own icons in the installer.

akismet-details

Plugin authors are at liberty to create their own custom 128px square icons, as seen in the Akismet example above. Nacin outlines the specific criteria for custom icons in the announcement:

Plugin icons are 128 pixels square. HiDPI (retina) icons are supported at 256 pixels square. Like banners, these go into your /assets directory and can be either a PNG or JPG. So just create assets/icon-128×128.(png|jpg) and/or assets/icon-256×256.(png|jpg) and you have an icon.

You also have another option: SVG. Vectors are perfect for icons like this, as they can be scaled to any size and the file itself is small. For an SVG file, you simply need an assets/icon.svg file.

If a plugin does not have a custom icon in place, an auto-generated icon will appear in the installer instead. Default icons are created from a color sampling of your plugin banner (done via Tonesque) and generated using the Geo Pattern library. This is all the more reason to add a custom banner to your plugin’s page on WordPress.org.

geo-patterns

Nacin credits Alex Shiels for his work on this beautiful new feature for the plugin installer.

If you are a plugin author and you want to have a custom icon in place when WordPress 4.0 launches, you can add one now. A custom icon will help your plugin stand out among the auto-generated icons. Check out Nacin’s tips on creating a custom icon for more information. WordPress 4.0 will be landing the week of August 25th. While you’re adding your icon, there’s still plenty of time to test your plugin with 4.0 to ensure its compatibility.

11 Comments


  1. The new layout for the plugins interface is attractive, functional and very welcome.The addition of a recognizable icon is also a welcome addition–any visual cue beyond having to read plain text is more than a cosmetic improvement. I’ve been doing the “bleeding edge nightlies” thing for several months now on a test site and I recommend it to anyone who has a test site they can spare for a few days or, better yet, a local testing environment. It certainly smooths the transition. Thanks to the 4.0 development team and beta-testers for all their hard work!

    Report


  2. very cool new feature that perhaps even helps in pushing plugin devs to update their plugins. Mine were already compatible up to beta version, but I used this to adjust it to 4.0 and included the new icon of course :)

    Report


  3. Here’s a thought: if we could filter plugins in our search, and limit it to those with an icon and/or banner, we could exclude all the plugins that haven’t been updated for years and may no longer be compatible…

    Report


    1. There’s no need for that: Plugins that have not been updated in 2 years don’t show up in search results. :)

      Report


      1. Doesn’t that depend on how you search? Through Administration, old ones are ignored; if through the WordPress web site they still come up (although with a note saying that it hasn’t been updated for two years or longer).

        Report


      2. Only exact matches show up there, in both places.

        Report


  4. The favorites feature was introduced a while ago but I don’t think it has been utilised properly yet. I think it would be great if you could install your favorite plugins with just a single click. Just a thought.

    Report


    1. Check out wpcore.com, if you’ve not. It’s a relatively new service that allows bulk installation of plugin collections. I’ve only just begun using it, but looks pretty slick.

      Report


  5. I know this is a 6-month-old post…but I needed a place to vent a recent peeve, and this is the closest fit I could find. It may never get read, but at least I’ve said my piece. ;)

    So, the plugin repository is now prettier and easier to search, but why does there seem to be no focus on making plugin versions more manageable?

    In particular:
    1) Allow replacing a plugin – with older, same, or newer version – via uploaded .zip
    2) Allow downgrading a plugin via integrated selection of a prior version (rather than manually getting the .zip from the Developers tab).
    3) Allow ignoring an update notice for a particular version of an individual plugin.

    These would help greatly in this situation: You are using plugin X version 1.00. 1.01 is released, which you install but find it breaks something important. In this case you want to be able to easily go back to 1.00. You also want to ignore the update notice for 1.01, but you *do* want an update notice for 1.02 (which, hopefully, solves the issue).

    Based on support comments I’ve read for several plugins, the need for item 1 is common. I even found a plugin intended to solve it – but it did not work.

    Items 2 and 3 are more icing – but the cake is pretty plain without them. The update notice sounds trivial, but for those of us who like to stay current, it’s annoying to see the notice when I don’t intend to use it. Plus I’m always concerned I might accidentally update it (and be left, again, in the situation where I need to do a clunky downgrade).

    These tasks are currently manual and error prone. It would be really nice if there was a graceful way to handle them.

    Report

Comments are closed.