Menu Search
Jump to the content X X
Smashing Conf Barcelona

You know, we use ad-blockers as well. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

Responsive Images With WordPress’ Featured Images

It’s been a couple of years now since the concept of responsive design took the Web design world by storm, and more and more websites are going responsive. But there are still some barriers and potential problems, not the least of these being the challenge of reducing the size of files that you’re sending to mobile devices.

In this article, we’ll look at how to use WordPress’ built-in featured images capability to deliver different-sized image files to different devices. “Featured images,” sometimes referred to as thumbnails, is a feature of WordPress that has been vastly improved since version 3. It enables you to specify a featured image for each post and display it with the post’s content.

Further Reading on SmashingMag: Link

The fact that the image is stored in the post’s meta data, rather than embedded in the post’s content, means we can use it more flexibly, as we shall see.

Why Worry About Image Size? Link

OK, so a lot of people do use their mobile devices to surf the Web while sitting on the sofa, hooked up to their Wi-Fi, one eye on the phone and one on the TV. And many browse for information sparked by a conversation with the people around them. This type of website visitor is becoming more and more common. You might even be reading this article in this way right now.

But there are and will always be people who use the Web from a mobile device while out and about, possibly using 3G in an area with a dodgy signal or on an expensive data plan. We Web designers and developers tend to invest in data plans with all the bells and whistles; but, believe it or not, plenty of people out there don’t use the Internet as much as we do and so choose a limited plan.

These people won’t thank you for using up their data by sending huge image files to their devices. They may well abandon your website before looking at it if the image downloads are slowing everything down. Moreover, mobile visitors might only check your website quickly in the middle of doing something else, and a slow website could harm your search engine rankings. Taking all this into account, surely reducing file sizes for mobile devices is a no-brainer.

Responsive Images: What’s It All About? Link

By now, you probably know what responsive design is: it uses a combination of a fluid layout and media queries to define breakpoints at which a website’s layout or content changes to fit a particular screen size. Most responsive websites use media queries to target phones; some target tablets such as iPads as well.

In the early days of responsive design, making your images responsive meant using CSS to ensure they stayed nicely inside their containing element, with this code:

img {
   max-width: 100%;

This technique makes the images look tidy, but all it really does is shrink the same large image to fit the layout. It does nothing to alter the actual size of the file, which could lead to huge image files sneaking onto your mobile design and seriously slowing down the website. Displaying large images that have been shrunk with CSS is discouraged by the W3C, and it uses processing power and data, so it’s a particularly bad idea on mobile devices.

When we do responsive design now, we generally include some way of making the image’s actual size smaller, using one of a variety of established techniques.

More Than One Way To Skin This Cat Link

If you’ve taken an interest in responsive design, you’ll have noticed that quite a few methods of delivering truly responsive images have emerged. Here are some of those methods:

  • Replace images in the markup with background images, using images of different sizes depending on the device. This method has serious accessibility and SEO drawbacks because the images don’t have alt tags for screen readers to read or search engines to index.
  • Use a smaller image in the markup and a larger image as the background of the containing element in the desktop version of the website, and then use CSS to hide the smaller image on larger screens. This method, described in detail by Harry Roberts on CSS Wizardry5, is better than the first one, but it does require that you manually create two images and then, in the style sheet, define the background image for every single image on the website. I don’t know about you, but I certainly don’t have the time or patience for that!
  • Use a JavaScript-based solution that employs URL parameters or data attributes. This avoids the repetitive work above, but it involves more processing and can slow the website down6—the opposite of what you intended.
  • Use a solution such as Matt Wilcox’s Adaptive Images7, which does the work for you. This is the smoothest option I’ve seen, but it requires that you separate the images that you want to be resized from those that you don’t—a potential problem when handing over a CMS-based website to a client or editor who isn’t technologically savvy.

The fact that Adaptive Images uses PHP got me thinking about how this could fit WordPress, which, after all, is written in PHP. Is there a way to use WordPress’ built-in functionality to deliver responsive images in a way that the client would not be able to break?

The answer is yes… with the addition of just one free plugin.

WordPress Responsive Images: Making It Work Link

I’ll demonstrate this technique using a website that I recently developed for a client, What’s a Mayor For?8. This website is responsive and gets a significant portion of visits from mobile devices. At the moment, it uses max-width to resize images, but it doesn’t send different image files to mobile devices.

This is what the website looks like in desktop and mobile browsers:

The whatsamayorfor site on desktop browsers9The whatsamayorfor site on mobile devices10
Click on the images for a large preview.

As you can see, the images scale to fit the layout. But what you can’t see is that the image’s actual size stays the same. We need to change that.

The solution we’ll follow here uses the following elements:

  1. A free plugin called Mobble, which detects devices and provides conditional PHP functions that you can use to deliver different content to different devices in your theme’s files;
  2. The single.php and page.php files, which we’ll edit to display the post or page’s featured image, but altering the image’s size according to the type of device;
  3. The featured image functionality in WordPress’ dashboard, which we’ll use to define the image used for each post and page.

Let’s get started!

Download the Mobble Plugin Link

First, download the Mobble11 plugin. This will check the browser’s user-agent string to determine which device the user is on. These checks are wrapped in WordPress-style conditional functions, such as is_mobile(), which is the one we’ll be using. Purists will balk at this approach, but in my experience it’s very reliable, and the plugin does get a high rating in WordPress’ repository.

Download and activate the plugin.

Edit the single.php and page.php Files to Call the Post’s Thumbnail Link

Using a text editor or WordPress’ editor, open the single.php file. Find the following code or something like it:

<article id="post-<?php the_ID(); ?>" <?php post_class(); ?>>
<h1 class="entry-title"><?php the_title(); ?></h1>
<section class="entry-content">

In our example, the image needs to be displayed immediately after the heading and before the content, so our code needs to be inserted between the h1 and section tags. If your website’s theme doesn’t use HTML5, you may put a div there instead of section.

Here is the code that displays the featured image for a given post:

<?php the_post_thumbnail(); ?>

The function has some parameters that we can use, the most relevant being image size. You can use any of the sizes defined by WordPress:

  • thumbnail
    Thumbnail: by default, a maximum of 150 × 150 pixels
  • medium
    Medium resolution: by default a maximum of 300 × 300 pixels
  • large
    Large resolution: by default, a maximum of 640 × 640 pixels
  • full
    Full resolution: the original uploaded size

This is where our conditional function plays with the image’s size. Here is the full code we’ll need:

   if (is_mobile()) {
   } else {
} ?>

This code does the following:

  1. Checks whether the website is being viewed on a mobile device: if (is mobile());
  2. If so, outputs the medium resolution of the post’s thumbnail (or featured image): {the_post_thumbnail('medium')};
  3. If not (i.e. else), outputs the large resolution: {the_post_thumbnail(large)}.

Having set up the single.php file, let’s do the same for page.php. Then, we need to change any embedded images to featured images via the WordPress dashboard.

Adding featured images in WordPress has been very simple since the functionality was incorporated in the user interface in version 3.0. Just follow these three steps:

  1. In the WordPress dashboard, open the editing screen for each post and page.
  2. Delete the existing image (it will remain in the gallery for that post or page, which will be helpful in a moment).
  3. Click “Set featured image” in the bottom right of the screen.
  4. In the “Set featured image” pop-up, click the “Gallery” tab. The image you just deleted will be displayed. All you need to do now is click “Use as featured image,” and then click the little cross in the top right of the window. Don’t insert the image into the post or else the image will be displayed twice.The WordPress featured image uploader12
    Large preview13.
  5. Finally, click the “Update” button to save the changes that you’ve made to the post, and test it.

Summary Link

As you can see, using WordPress’ featured images functionality to make responsive websites faster on mobile devices is a fairly simple process. All it takes is three steps:

  1. Install the Mobble plugin.
  2. Add conditional tags to the single.php and page.php files to call different versions of the image depending on the device.
  3. Replace images in the body of the content with the featured images.

Of course, this method isn’t perfect for all situations. It only works if the image should appear above (or below) the rest of the content, and it does require that anyone who adds a post or page use the featured image functionality instead of just inserting an image in the body of the content. All you need to do now is educate the editors of your website to use featured images instead of images within the content. But how you do that is for another day!


Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13

↑ Back to top Tweet itShare on Facebook

Rachel is a freelance web designer and writer specialising in mobile and responsive WordPress development. She's the author of 'Mobile WordPress Development', a comprehensive guide to making yourWordPress site mobile-friendly, published by Packt, and also author of 'WordPress Pushing the Limits', published by Wiley.

  1. 1

    Martin Czerwinski

    June 15, 2012 2:06 am

    Pretty nice. What I use to do, when working with post thumbnails is wrapping the_post_thumbnail() with a custom function, like this:

    function mc_the_post_thumbnail () {

    // Using is_mobile():
    if ( is_mobile() ) {
    $size = ‘medium’;
    } else {
    $size = ‘large’;

    if ( has_post_thumbnail() ) {
    the_post_thumbnail( $size );
    } else {
    // Display default post thumb here, if not set

    I can display a default thumb, if none is set, and it keeps my template files tidy.

    • 2

      Or you could create a filter to the_post_thumbnail’s generating function itself (post_thumbnail_html I think) and add the mobile detection in there, so you can avoid renaming functions elsewhere in your theme.

      I hope this same principle can apply to the rest of the images inside an entry, because that’s where the chunk of bandwidth will be used. :)

    • 3

      The perils of UA Sniffing aside, i think this is a sensible approach

  2. 4

    Thanks for this.
    We are just starting to build responsive designs the last month and for some projects we are going to use responsive images…
    Until now we did that server-side and delivered smaller images to Smartphones… but for optimizing performance another solution would be great…
    We will try…

  3. 5


    I think that the idea of detecting the apropriate image size using user-agent property is just a step backward.

    Wouldn’t be better to put in the html three different versions of the image tagged with classes “small”, “medium”, “large”? The images would be shwon/hidden using css media queries. As far as I remember hidden images are not downloaded by the browser and this approach does not depend on risky user-agent tests.

    • 6

      ^This. I’ve always been leery of user-agent tests, so any move away from that is definitely worth investigating

    • 7

      The way I understand it, it depends on the way you build your site.

      If you start from a mobile view and use Media Queries to scale the site up, the browser won’t download the larger versions of the images because it sees that they are “display: none” and the Media Queries hide your reveal of the images from the mobile view.

      But…if you start from a desktop view (where the large images aren’t hidden by default) and use Media Queries to scale the site down, it will download every version of the image because it first thinks the large one is showing, then when it hits the “medium” query it will think the medium one is showing, and then when it hits the “small” query it will think the small one is showing.

      That’s been one of the biggest arguments I’ve heard for “mobile first” development, so I can only assume that it’s true. I’ve never tested it, myself.

      • 8

        I have some bad news for your approach – “display:none” does *not* prevent your image from downloading. All images using an img tag are downloaded – the CSS setting is completely independent and not considered by the browser – this is true for all major browsers.

        A really good and free tool to test things like this (at least on Windows) is called Fiddler2. You can see the http requests for the images for your yourself, irrespective of the CSS settings.

    • 9

      I am almost certain that you are mistaken concerning hidden images not being loaded.

      In fact using hidden images at the end of the a page is a way of preloading images to be used later in the site. Not only are these hidden images loaded but they are also cached which then means that they could be displayed on another page of your site without extra requests.
      *Note that this is not the best way of preloading as it delays the “load” event.

      So as I understand your method would load 3 times the images every time, which is of course not what you want.

      • 10

        I tried Fiddler2, and images with display:none were downloaded, but background images were not. So you could presumably create a solution without plugin or javascript. Double-check me but I couldn’t see a request for the background.

        My issue with plugins, as a theme author, is there’s no guarantee the user will not remove them. Or that they’ll install them in the first place. As for javascript, I don’t want to rely on it for a mobile design, because of a known issue with Android, where many users cannot Google anything if Javascript is enabled, so they all had to turn it off. Search on ‘android search broken’ & you’ll see what I mean, lots of threads about it.

        Since I use the mobile-first approach, I’ll try all my thumbnails in the background. We’ll see if I hit issues. If that doesn’t work, I’ll try the srcset attribute.

        • 11

          Depending on the plugin your using, you could make it a WordPress MU Plugin, that will prevent users from removing or disabling it at least. Or hardcode it in your functions.php file, again depending on your plugin and how adventurous your client is at looking under the hood.

    • 12

      Wrong – files hidden using css are downloaded but not displayed. Media queries alone do not solve the problem. However, this solution from Jeremy Keith using a combination of media queries and javascript worked nicely for me:

    • 13

      Denis Leblanc

      June 15, 2012 9:31 pm

      I believe that’s incorrect. Assets do get downloaded regardless of setting it to display: none. If it’s in the CSS file it’s a request.

      • 14

        The image can be avoided from download, only if it is set as background image with CSS and that has visibility:hidden, if my memory serves me correctly – this technique is often used when emploring “lazy loading” image techniques.

        – word.

  4. 15

    ECMS is able to resize images on server side, according to http request parameters. So, you can adjust display by using JS on client side.

    Also, there is a “scale” template variable that can be used to automatically adjust all images’ size.

  5. 16

    So, I remember reading some articles saying that sniffing is outdated, probably right here on Smashing. How sure can we be of these tests as there are a lot of devices out there? And how useful will it be in the near future when new devices will appear and maybe have different responses on these tests?

    • 17

      Oh, I love the bookstore arnergad by color! That would be tricky to navigate, though. I keep wanting to arrange my books by color, and then I realize that most of them have boring academic covers in neutral colors that wouldn’t make much of an impact. Oh well.

  6. 18

    Christopher Gladney

    June 15, 2012 5:44 am

    I just hopped on Smashing considering the very question of image resizing in responsive design within WordPress – can’t believe it is the very first thing I stumbled upon! I love how this method works but am wondering how it could be extended further into other site images or images populated on pages through custom fields. If we could apply this same methodology to custom file fields, the possibilities would be endless. Awesome post Rachel – thanks!

  7. 21

    Looks like there’s more ways to fillet felines these days. Thanks!

  8. 22

    Barry Hughes

    June 15, 2012 7:13 am

    Marcin: it probably varies from browser to browser, but I suspect the image *is* downloaded even when display is set to none – it just isn’t rendered either on or off screen.

    Something I’m wondering is if we use are going to use user agent data in this way, would it be possible to leverage mod_rewrite or equivalent to do the heavy lifting? For instance the file extension (say “.jpg”) could be conditionally replaced (with “_small.jpg” … assuming the relevant _small version of the image already exists, of course).

    In fact, taking that idea a step further, a more precise value for either width or height could be appended: “_192px.jpg” or whatever. The rewrite structure could be either to serve that file if it already exists or use an image server script, whether TimThumb or something else, to build the resized image and save to the image cache.

  9. 23

    Ramon Fincken

    June 15, 2012 10:22 am

    Exellent, yet you need to tweak your page caching plugin to make sure your visitors get mobile cached when on mobile and desktop cached when on desktop.

    • 24

      Evan Jacobs

      June 17, 2012 1:32 pm

      This was my concern as well – caching.

      It seems like responsive image switching is better done on the client side with JS than server side. My setup is serving mobile images by default and then switching them for full-res if the viewport is wider than 800px or so.

      I only notice a slowdown on very large images, and with a desktop you’re much more likely to have a quicker connection, lower latency than mobile.

  10. 25

    How would this method handle 2x images for retina iPad separately from “mobile” or 2x images for the new retina MBP separately from other MBPs?

    • 26

      Evan Jacobs

      June 17, 2012 1:33 pm

      It would detect the new iPad / iPhone 4S via the same sniffing method and I guess use something like is_retina

  11. 27

    Congratulations, you just served Google TV users on their 42″ screen a tiny image optimized for mobile. Same goes for all tablets which are not an iPad or a Galaxy Tab, because Mobble checks only for these (source)

    So yes, sniffing for the user agent is a very bad idea.

  12. 28

    And for images inside posts ?

  13. 29

    This week I was playing with some of a themes Responsive styles. I will need to try this Mobble plugin and see how it works out. Martin I like your in-code conditions are you not doing that anymore because of constraints or just new products like the one discussed here?

    • 30

      Martin Czerwinski

      June 16, 2012 1:23 am

      As some others commented browser sniffing is not best practice. You can never be sure, if new devices dont fit your plugin and get served the wrong image. I’d like to see new features like the img srcset some vendors are experimenting with currently, that serve images according to size. But for as long as most browsers dont support that, the method above works good.

      I need to experiment with responsiveness though.

  14. 31

    Bram Willemse

    June 15, 2012 12:43 pm

    Nice read, although I have the idea it could be a bit more elegant. I’m not sure about using Mobble and I’d say: use the add_image_size(); function instead of thumbnail / medium / large for better customization.

    I haven’t done anything yet with responsive images though, so I might give this a try :) Thanks!

  15. 32
  16. 33

    Molly Campbell

    June 15, 2012 2:07 pm

    Does this only allow you to use one image per post? I’m assuming so, but figured I’d check.

  17. 34

    Tessa Thornton

    June 15, 2012 2:39 pm

    I recently used the noscript technique ( in a wordpress theme, and while it is highly inelegant, it works. As with anything, this is all pretty context-dependent. In my case, it was 3 slider images that needed to be not loaded on mobile, and the additional markup was negligible, and the whole thing is just entirely ignored by mobile browsers. I get the whole idea of “content parity,” but when I’m browsing to my university’s student services site on my weakly-connected phone, I really don’t want or need to see 3 pictures of students smiling, and screen reader users likely don’t care to hear about it.

  18. 35

    Wish I could use this also for serving high-res images to Retina displays. The Mobble plug-in can detect iPhone & iPad, but not if it’s a Retina device…

    • 36

      Evan Jacobs

      June 17, 2012 1:37 pm

      Very easy to do with JS:

      var retina = window.devicePixelRatio > 1 ? true : false;

      I guess take a look at user strings for retina devices and see if there is a difference that could be exploited for detection.

  19. 37

    Elliott Richmond

    June 15, 2012 11:49 pm

    Interesting technique and I’m keen to try it out – thanks for the share Rachel. No subscribe to comments makes me sad :-(

  20. 38

    We have some serious hurdles to jump before we get a perfect solution. My main concerns are:

    > Bandwidth
    > Mobile context
    > Retina displays

    In my humble opinion, only browsers can efficiently handle these decisions. Until spec’s catch up with current tech, we can only attempt a part-solution.

    For WordPress, I build sites using

    > Media queries and percentages for general responsiveness to screen resolution
    > I offer smaller screens a choice to view a ‘low-bandwidth’ theme that pulls in ‘mobile-optimised’ images – It does mean content creators need to create two images. Easily done by cropping images to re-focus on their ‘main’ part in addition to reducing the image size (all done via WP Admin).
    > Be pragmatic given the current failure of specs to match real-life tech advancements. We are NOT wizards!

    Still, a thank you to the author for showing us how to magic-up a solution. Even if browser-sniffing is a broken method…

  21. 39

    Here’s the challenge to this method – if you are in a high-performance WordPress configuration where there is significant caching, this method does not work. The request for the correct image really needs to come from the client.

  22. 40

    Well in my opinion, the smashing magazine itself looks quite responsive and its layout changes when I resize the browser window. How could you make it?

  23. 41

    Dylan McCall

    June 17, 2012 2:50 pm

    I was pretty excited to see an article about images for responsive web design and WordPress, because I’m going to be working with exactly that on a site I’m doing :)

    However, while this is an awesome solution for a site with a mobile version (and I appreciate the summary of other approaches), I don’t understand how this solution relates to responsive web design. Responsive web design is all about the current shape of the viewer. Here you’re just checking if the browser is a mobile browser and serving different content from the server. That has nothing to do with the viewing environment. If I happen to have a web browser that is 400px wide on a _desktop_ browser, I am still served a huge version of the image. If I use a particularly large tablet or plug my phone into a big screen, I’m getting a tiny image scaled well above its proper size. Further, even if the browser happens to change its user agent as its size changes (please no!), getting the correct image is a page load away. I am imagining a world of hurt trying to fit this technique alongside a fluid, percent-based layout as in responsive web design.

  24. 42

    What about
    I’ve got this working with WordPress just fine.

  25. 43

    Jeremy Tarpley

    June 18, 2012 6:46 am

    This is great, thanks!

  26. 44

    Ricardo Miller

    June 18, 2012 2:03 pm

    So doesn’t anyone think the timthumb script is any good then. I am using the WordPress featured image function but i am using it with the timthumb script some like this
    $wp_thumb = wp_get_attachment_image_src(get_post_thumbnail_id(),’size’);
    if((function_exists(‘has_post_thumbnail’)) && (has_post_thumbnail())){
    echo ‘img alt=”” src=”timthumb.php?src=$wp_thumb[0]&w=width&h=height” />’;
    this options works fine for me because timthumb script resize the image and reduce its size. So would you not think this can work on mobile site as the original image size would have been reduce by the script it self and i also use the image resize css method describe above to scale the image

    max-width: 100%;

  27. 45

    Rachel McCollin

    June 20, 2012 7:24 am

    Hello and thank you to everyone who’s commented! There are so many comments I can’t possibly reply to them all individually.

    However I realise there are concerns about UA sniffing and I share them. I agree that we are still working towards the ideal solution on this one.

    I’ve been talking to a contact about a plugin which would use JS for this which I hope will solve the issue – watch this space.

  28. 46

    Csaba Erdei

    June 22, 2012 8:27 am

    I think it would be better to use WP’s ‘post_thumbnail_size’ filter to change the image size, so you don’t have to edit template files:

    Something like this (not tested):
    add_filter(‘post_thumbnail_size’, ‘my_mobile_image_size’);
    function my_mobile_image_size($size) {
    if (is_mobile()) return ‘medium’; else return $size;
    (line 87)

    Anyway, nice article, good idea.

  29. 47

    Dave Wright

    June 25, 2012 2:15 am

    I’m sure that in time the de-facto standard for this kind of thing will emerge. I’m having some success experimenting with…

    The script not only allows me to target specific devices with specific image sizes it also gives me a load of conditional tags like is_mobile(), is_tablet(), is_kindle(), is_opera()
    Yes it is UA sniffing but like all things that are bad for us they often taste soo good!!!

  30. 48

    “Use a smaller image in the markup and a larger image as the background of the containing element in the desktop version of the website, and then use CSS to hide the smaller image on larger screens. This method, described in detail by Harry Roberts on CSS Wizardry, is better than the first one, but it does require that you manually create two images and then, in the style sheet, define the background image for every single image on the website.”

    Actually, you DON’T need to create two images, if you are using post thumbnails anyway. Whenever you upload an image (at least with post thumbnails, have to check with the rest) WP creates a version for every size you have defined in your functions.php. So, you can safely use this method and include the small image because WP will already create the big one for you. No need for a plugin or user-sniffing here, just a couple of lines in functions.php.

  31. 49

    I must admit that i’m not a fan of the current solutions. If you’re in the business of WP CMS building there is just no way the client will not muck things up, creating more work for you in the long run.

    Javascript still seems to rock when it comes to sniffing physical sizes of the user agent and I’m gonna investigate those solutions for robust responsive images instead.

    Thanks for the recap either way!

  32. 50

    I believe the server side UA sniffing is the most viable approach CURRENTLY to deliver responsive images.

    Why? It is the fastest and least processor-heavy technique to deliver the appropriate image. It simply detects the mobile device, and delivers the image file that is linked to that size. No javascript, css or html hacks required. Javascript solutions are quite ugly and are temperamental, so the results will be less accurate than the UA method.

    The downsides? You are relying on the user-agent string, but is this really such a bad thing? Most users won’t even know how to change their user-agent on their computer yet alone mobile device, so for most of the population it will work. And if you are using a mobile user agent string on a desktop for non-dev purposes, well that’s just silly! Also keeping a list of UA strings is cumbersome and will require regular updates to the server side code.

    I’ve created a plugin for WordPress called Responsage that creates responsive images for WordPress, and it works flawlessly. Its all automatic so you only need to upload a desktop version and the mobile images are automatically created and delivered.

    UA responsive images is definitely not the future, but I don’t believe extra html markup and javascript or css solutions are either.

    I think the detection should come from a standardized set of inbuilt functions in mobile browsers, maybe something similar to how Apple detects retina icons in applications (appending @2x to the icon filename is detected by retina devices and is displayed automatically, maybe @mob and @tab for the web???). This way, the image source is filtered before any requests are performed, and web developers don’t need to include a custom solution that will work less efficiently.


  33. 51

    Carlo Rizzante

    March 12, 2013 6:30 am

    Nice solution, but it works for only the featured image or thumbnail of the post. What about all the other images in the article?

    I’m investigating how to apply responsiveness to the images into WordPress and so far I’m toward rewriting the routine that inserts pictures from inside the Editor into the content. In a way that it will use the sintax, and perhaps Picturefill ( ).

    Sort of… ’till WordPress itself will not have a proper built-in solution by itself. Perhaps also a bit of Javascript to substitute a simple with a more complete routine. After all, creating different sizes of each image it’s something WordPress already does with no hassle.

  34. 52

    Great tutorial, simple but efficient. I like things this way.

  35. 53

    Morgan Feeney

    January 5, 2014 3:37 am

    Hi Rachel, I like this approach and I think that it covers the majority of the solution. The conditionals using Mobble work really well before the page loads as PHP is inherently server side. However what is your method, if any, for resizing your browser to smaller widths and then back again? The smaller images which will load on a smaller width will break the layout if the width of the browser goes to say full screen width.

    I understand that the main ethos here is to provide a good experience for the majority of users, which this does. However I tend to be a bit OCD; and just knowing that the possibility of my design/layout breaking just eats away at me.

    So anyway, yes the users with large screens will more than likely get the large image on page load as the screen width will trigger that conditional. That solves the issue (kind of), and the users who have a mobile device or tablet will trigger the smaller images on page load. What bugs me is the bits in between which aren’t covered by using this technique.

    • 54

      Morgan Feeney

      January 5, 2014 5:03 pm

      Hi again, I have been experimenting with this technique today and actually see no issues whatsoever. It makes way more sense to use conditionals in PHP than having to change images based on screen/browser width/resizing. I was thinking that maybe there would need to be a javascript image replacement method changing the different images, D’OH!!!

      And then there’s the fact that only the device being used will get the image which best suits it’s screen size.


  36. 55

    Our major challenge is making this work with image sliders. We have experimented with creating various image sizes for each image to conform to our media queries in the CSS file. We then use separate sliders created for each of 3-4 breakpoints ( sliders are named with the breakpoint info so our clients can figure it out easily ) and serve up only the sliders called by mobile device need. So far, it seems this method works by only loading the images by the device – somehow the slider backend is helping to mask the larger images as we are using CSS “display: none;” parameters to hide the content not called for on each breakpoint.

    I have tried other solutions myself with limited success. We are considering using TYPES and VIEWS plugin within WordPress to create “dynamic slider views” that call the various “featured image sizes” controlled in the front end “settings/media” parameters and also overwritten by our functions file.

    Always a fun challenge for sure. Woody.


↑ Back to top