Fun with High-DPI displays

With the release of a lot of high-DPI displays (aka “retina” displays, but also others on both Android and iOS devices), it’s just a truism that images on these displays have tended to not look their best, all the time. High-DPI displays are having to scale up low-resolution images, and it’s just not great.

There is a simple solution for this, using either CSS or Javascript tricks, but the basic principle behind it is to make an image twice as big on each dimension (four times the area), and then let the browser scale it down into the space it’s supposed to fit into. This lets the high-DPI displays have more information to work with and to make images which scale much better. The problem, of course, is that larger images require more space and bandwidth. With various CSS and JS techniques, you can target it such that the high-res images are only sent to browsers that really need them, saving on the bandwidth.

Anyway, lately we’ve been making those sorts of changes to too. If you’re visiting on a high-DPI display, you may notice that the main header logo is of a higher quality, or you might have noticed that the Showcase looks particularly good, or that we now have some very high resolution images on the Logos and Graphics page. Little changes to the graphics, here and there. It’s an ongoing project to “retina-all-the-things”.

Back in December, we made some changes to allow plugin authors to put banner images above their plugins in the directory, and the response has been great. So, now they get the high-DPI love too.

Plugin authors already have the ability to make a banner-772x250.jpg or png file in their assets directory and have that be used for the banner image on their plugin listing. As of today, they can add a banner-1544x500.jpg or png file, for use on high-DPI displays only. When the website detects that the viewing browser both has a high-DPI display and the high-res image exists, then that image will be shown instead of the low-res image, but scaled to fit into the proper space. This makes them look particularly sharp on high-DPI displays.

Now, before you go forth and create, please remember that one thing to keep in mind here is filesize. If you’re using photographic material for your banner, then it is highly recommended that you use the JPG file format. If you’re using drawn or generated materials, PNG is the favored format. However, in either case, you will want to apply high compression and try to keep those files as small as possible. Small files transfer to the browser faster. Also consider that a fair number of high-DPI displays will be phones, for example, and perhaps not using high-speed connections. So keeping that high-res file as small as you can would be a good thing. If you wish to use a PNG compression tool before uploading, that might be a good idea as well.

And there you have it. Plugin authors, go forth, and show us your high-resolution banner skills! 🙂

BTW, if you want to see it, I gave my Pluginception plugin a high-res image, for testing. It’s a simple image with some well-defined lines that make the difference easy to spot if you’re looking for it. You’ll need a high-DPI display to see it though. 🙂

#plugin, #retina, #wordpress-org

I’m going to be upgrading the extend themes…

I’m going to be upgrading the /extend/themes bbPress install to bring it up to the same level of bbPress where the ideas and plugins and support forums are. This is to allow the login cookies to integrate properly across the whole site.

This means that parts of the themes directory will be non-functional or broken for short periods of time as I track down issues with it. These times should be short and as minimal as possible.

#extend, #themes, #wporg

Theme pages now have a little “Theme SV…

Theme pages now have a little “Theme SVN” link in their FYI box. This just gives a link to the theme’s SVN, for people that want to use it.

This is something several of the theme reviewers asked for, and it fits with the long term goal of allowing some theme authors the ability to directly update themes via SVN instead of using the ZIP file uploader. Encouraging SVN use is a good thing, I think.

#extend, #themes, #wporg

I added child theme support to the theme…

I added child theme support to the theme previewer for /extend/themes. The only child theme we have in there at present that I know of is this one: , but now the preview works for it. Note that the parent theme of a child theme must also be in /extend/themes for this to work.

#extend, #wporg

Added a new page to http:…

Added a new page to
Also added it to the dropdown menu under extend.


It was pointed out to me that I never me…

It was pointed out to me that I never mentioned it anywhere when I made this change last month, but the plugin search engine at has been much improved. So now when you search for things like “buddypress”, you should get what you’re looking for on the first page of results more often.

It was a minor adjustment, so it didn’t occur to me to tell anybody. Sorry about that. 🙂

#extend, #plugins, #wordpress-org

Profiles now shows up-to-date info from …

Profiles now shows up-to-date info from the various trac installs once again. It won’t be up-to-the-minute, but it will be updating on a somewhat regular basis.

#trac, #wporg

The theme uploader tool now performs a m…

The theme uploader tool now performs a much more extensive scan of uploaded themes and gives the results back in a list format to the uploader. Hopefully this will allow theme developers to more easily fix problems with their themes and reduce some of the load on the theme review team.

Example of the resulting output (truncated). Note that I intentionally used a failed theme here, to show an example of what that looks like.

And so on. This is an improvement over the previous method, which just stopped at the first error found and didn’t give a whole lot of useful output. While that old system is still in place (for now), this one is there in addition to it and will give all the results for any theme uploaded.

#themes, #wporg

New and improved this morning, we have a…

New and improved this morning, we have a two-fer.

First, on the extend plugin directory, you may notice some new pie chart fun on the stats tab for each plugin. This shows a percentage breakdown of the versions being actively used by that plugin’s users. Only slices greater than 1.0% are shown.

Secondly, since data kept in a box is not very useful, there’s a new API for getting this data. Usage is fairly obvious from just a simple example, which gets the version breakdown of one of my own plugins:
The callback parameter is optional, of course, and provided for people who want JSONP usage.

Note that the version data is relatively new, so we don’t have it for all plugins at present. It will get better as reporting continues. For those interested, it’s saving the total counts of the version numbers as reported by the plugin update-checks over the last week. Since the data at present is only from one day, it’s not very accurate.

#api, #plugin-directory, #wporg

The codex now recognizes the single-sign…

The codex now recognizes the single-sign-on cookies and signs you in with them.

Note that MediaWiki has its own cookies too, so logout doesn’t quite work right. I’ll work on that soon.