kylereicks

Let me try working through this and see if we get closer to where we want to be.

We start with creating the banner image sizes in functions.php.

add_action('init', 'add_banner_image_sizes');

function add_banner_image_sizes(){
  add_image_size('banner-large', 2000, 210, true);
  add_image_size('banner-medium', 1300, 210, true);
  add_image_size('banner-small', 480, 210, true);
}

For this example, I’m going to assume that the ACF field is an image field named “banner-image” with the return value set to “Image Object”.

In the theme file for the banner, lets get the content of the field and add a filter called “theme_banner_image” that we can interact with later.

<?php
$image_object = get_field('banner-image');
$image_output = '<img src="' . $image_object['sizes']['banner-large'] . '" title="' . $image_object['title'] . '" alt="' . $image_object['alt'] . '" />';
echo apply_filters('theme_banner_image', $image_output);
?>

Back in functions.php let’s try filtering that image and sending it off to the plugin after telling the plugin what image sizes to use.

add_filter('theme_banner_image', 'theme_function_for_banner_image', 10);

function theme_function_for_banner_image($content){
  picturefill_wp_set_responsive_image_sizes(array(
    'banner-small',
    'banner-medium',
    'banner-large',
    ));
  return Picturefill_WP::get_instance()->cache_picturefill_output($content);
}

Let me know how that works, or if I have misinterpreted what you are trying to accomplish.

Thanks very much for your question.

Unfortunately it’s not super easy to do what you describe at the moment. For your use case, you might want to take a look at version 2 of this plugin over on GitHub, which doesn’t create any new image sizes. I think that might be closer to what you’re looking for.

I’ll have to think about this to see if I can make the kind of flexibility you describe work in the existing version 1 framework. The biggest strength and biggest weakness of the picture syntax is that it is very explicit, so flexibility can sometimes be a challenge.

Thanks very much for your question and for sharing your use case.

I’ve been using Chrome’s device emulation tool. I think that should work. Instead of choosing a device, you’ll probably just want to set the resolution and device pixel ratio manually.

I’ll report back when I’ve sorted something out with regard to the HDPI media queries.

I apologize for the headaches. There isn’t a super easy answer to what the breakpoints should be. We’re limited to media queries that look at browser width, and not container width. A theme may have a breakpoint at 768px, but maybe we want images to be in three equal columns above 768px and two equal columns below 768px. The sizes attribute tries to fill this gap, but the syntax can be a little confusing, and it isn’t something that is implemented with this version of the plugin.

So we’re stuck with media queries. I tried to make up for the limitations of media queries by including as much information as possible in the picturefill_wp_media_query_breakpoint filter.

add_filter('picturefill_wp_media_query_breakpoint', 'theme_breakpoints', 10, 6);

function theme_breakpoints($default_breakpoint, $image_size, $image_width, $image_attributes, $image_attachment_data, $image_sizes){

/*
Let's say we just want to have the breakpoint equal the image width.
*/

  return $image_width;

/*
Or maybe we have a 32px margin around each image. In that case
we'll want width + 32 + 32.
*/

  return $image_width + 64;

/*
Or maybe we want a more seamless responsiveness, so we'll set
the breakpoint to the width of the image below the current one
in the queue.
*/
  // First we find the position of the current image size in the list of images
  $image_size_index = array_search($image_size, $image_sizes);
  // Next we set the index for the next image size down
  if('@2x' === substr($image_size, -3)){
    $new_index = $image_size_index - 3;
  }else{
    $new_index = $image_size_index - 2;
  }
  // Lastly, we set the breakpoint to the width of the next smaller image size. If the image is already our smallest, we set the breakpoint to 1.
  if(0 <= $new_index){
    $new_breakpoint = $image_attachment_data[$image_sizes[$new_index]][1];
  }else{
    $new_breakpoint = 1;
  }
  return $new_breakpoint;
}

I think these three scenarios (image width, width + margin, and width of the next smallest image) will cover a lot of use cases, but obviously not all. An image in a sidebar may need to be “thumbnail” sized at desktop widths, but when on mobile when the design drops to a single column, it may need to be “medium” sized.

The documentation could always be better. I’ll dedicate some time to making it more clear after I squash this HDPI media query bug that is floating around.

Thanks very much for posting your questions. I know I’ve thrown a lot out there, so if there is anything that needs more explanation, or if there’s something I missed that should still be addressed, don’t hesitate to bring it up.

Thanks again,
Kyle

It looks like the source elements are in the wrong order. They are appearing as small, extra small, and post thumbnail. It looks like small and extra small have been reversed.

If you are able, please post the code you are using in your theme to customize the plugin. That way I can see if it is a bug in the plugin or if there is something that needs to be addressed in the documentation.

I apologize for the lack of clarity on the GitHub page. I have since added a note on the two versions so hopefully the documentation for version 1.3 is a little easier to find. https://github.com/kylereicks/picturefill.js.wp/tree/1.3.x

Thanks very much for reporting the issue.

I think I have the issue duplicated. It’s only occurring on high resolution devices (or emulated high resolution devices). The resolution media query is being matched, but the browser width media query is being ignored.

In your provided example everything works as expected at 1x resolution. At 2x resolution, picturefill.js only outputting the “retina large” image, regardless of the browser width. Since it is not grabbing the “full” image size, we can tell that the resolution media query is being respected, but the width media query is not.

I will have to play around and see if this is something that can be fixed by refining the media queries, or if there is a bug in picturefill.js.

Thanks very much for reporting the issue.

I’m glad that things are working again. I’m not sure exactly what happened, but I know occasionally I forget that the network admin treats plugins and themes differently.

Themes need to be “network enabled” from the network admin before any individual sites have access to them. Plugins are accessible by all sites on installation, but can be “network activated” for all sites at once. This is easy for me to forget and I’ll wonder why a theme isn’t showing up or why a plugin is already activated.

Thanks very much for reporting back.

I’m afraid I’m having trouble duplicating the described issue in my development environment. I’m going to try a fresh install and see if that makes any difference. I apologize for moving slowly on this. I’m dedicating most of my free time to getting Picturefill.WP 2 ready for release. I plan to continue to maintain version 1.3.x, so finding this issue is still a priority.

I am pushing version 1.3.5 with a few unrelated bugfixes. I don’t expect that they will address your issue, but if something magically changes let me know.

Thanks very much.

Hi Zack, thanks very much for the thoughtful feedback. You are touching on a few of the more difficult design challenges that have come up with this plugin.

First, you are absolutely right about the misnamed attribute in the add_image_to_responsive_queue method on line 44 of functions-picturefill-wp.php. This issue was also brought up by hguiney on GitHub and should be corrected in the latest version 1.3.4.

One of the biggest challenges with a plugin like this is the user interface. I have decided to go in a different direction than many other similar plugins by not having an admin UI and keeping all of the configuration with code in the theme files. I believe this more closely reflects the WordPress philosophy by keeping design considerations segregated in the theme and left to the discretion of the theme designer/implementer. As you’ve struck on here, creating a flexible code based UI is challenging. I’m very often surprised by the use cases that come up. I’m dedicating most of my energy around this to Picturefill.WP 2, which is going to be a separate plugin using the new Picturefill 2.x syntax. I’m planning on maintaining both plugins, but updates to Picturefill.WP 1.3.x are going to be limited mostly to bug-fixes.

You have made good suggestions regarding documentation, and I will be sure to work those in as I re-evaluate the docs. Please continue to let me know when the documentation seems confusing or incomplete. It can be hard to read these things outside your own head, and external feedback is always welcome.

Thanks again very much for the detailed feedback.

Hi Zach, thanks for taking the time to post the issue. After working through a few other bugs noticed by others, I am not able to duplicate the behavior you describe, so it is possible that one of these bugs was the cause of our trouble. I pushed these bug fixes a few minutes ago with version 1.3.4. If you’re willing, give it another try with the latest version and see if the problem persists. If it does, I’ll do some more investigating and try to duplicate the issue.

Thanks again for the feedback.

Hi Hal, I did run across a bug in the picturefill_wp_set_responsive_image_sizes function that may have been causing some unexpected behavior. This also might be related to GitHub issues 32 or 33. Both uncovered bugs in the helper functions. With those fixes in place, the code you provide is behaving as expected for me. That is, outputting a medium or medium@2x size image depending on screen resolution.

I pushed all of these updates a few minutes ago with version 1.3.4. Please let me know if problems persist and I will investigate further.

Thanks very much for the feedback.

DOMDocument is included by default in the version of PHP required by WordPress (5.2.4). The error you describe likely means that your web host is using an older version of PHP, or has disabled the DOM or libxml extensions. You will have to talk to your web host about these issues. I could build a check for DOMDocument into the plugin, but I had assumed that it would be disabled very rarely. If you don’t mind my asking, who is your web host?

Thanks very much for your kind words Filip. If I understand what you are trying to do, I think we should be able to make these changes to the picturefill syntax from a theme’s functions.php file using a few filters.

In functions.php

// First let's override  picturefill.js with your custom script
add_action('wp_enqueue_scripts', 'override_picturefill_scripts', 11);

function override_picturefill_scripts(){
  wp_deregister_script('picturefill');
  wp_register_script('picturefill', 'https://path/to/custom/picturefill.js', array(), '1.0', true);
}

// Next let's reverse the order of the "source" elements
add_filter('picturefill_wp_image_sizes', 'reverse_image_queue');

function reverse_image_queue($image_queue){
  return array_reverse($image_queue);
}

// I didn't consider using a max-width media query when I was adding hooks to the plugin.
// We will have to use two filters to get the new media queries in place.

// First we'll set the numbers
add_filter('picturefill_wp_media_query_breakpoint', 'set_query_to_image_width', 10, 3);

function set_query_to_image_width($breakpoint, $image_size, $width){
  return $width;
}

// Then we'll filter the template to change min-width to max-width
add_filter('picturefill_wp_source_template', 'min_width_to_max_width');

function min_width_to_max_width($template){
  return str_replace('(min-width:', '(max-width:', $template);
}

I haven’t had the chance to test the code above, but it should get you moving in the right direction. I’ll look at this more thoroughly this weekend.

Alternatively, if you’re just looking for smooth responsiveness between the images, you should be able to get that effect from the plugin with something like the following.

In functions.php

function smooth_breakpoint($breakpoint, $image_size, $width, $image_attributes, $image_attachment_data, $image_sizes){
  // First we find the position of the current image size in the list of images
  $image_size_index = array_search($image_size, $image_sizes);
  // Next we set the index for the next image size down
  if('@2x' === substr($image_size, -3)){
    $new_index = $image_size_index - 3;
  }else{
    $new_index = $image_size_index - 2;
  }
  // Lastly, we set the breakpoint to the width of the next smaller image size. If the image is already our smallest, we set the breakpoint to 1.
  if(0 <= $new_index){
    $new_breakpoint = $image_attachment_data[$image_sizes[$new_index]][1];
  }else{
    $new_breakpoint = 1;
  }
  return $new_breakpoint;
}
add_filter('picturefill_wp_media_query_breakpoint', 'smooth_breakpoint', 10, 6);

Again, I haven’t had a chance to test the above code thoroughly but can look at it in more depth this weekend.

I hope this gets you moving in the right direction. I’ll report back this weekend with regard to the helper functions.

Thanks again

Thanks very much Craig. I’m glad to hear that it’s working for you. Every once in a while, a theme has a little trouble with the picturefill syntax. I can’t really blame them, the syntax is unusual. I’m glad you were able to find a solution for the issue you were having. If the issue with captions ends up being something that you notice consistently across different themes, please report back with the details of where it’s popping up and what it looks like, so I can try to duplicate the issue. If it’s a common issue with themes, and especially if it happens on any of the twentyX themes, it may be a good idea to mention it in the documentation.

Thanks again

You’re right, I hadn’t considered that use case. Thanks very much for bringing it to my attention.

I really like your idea. It could save the trouble of checking if the post had been updated since the transient was set. I’m going to do a little research to make sure there aren’t any performance implications I’m not thinking of, but a hash sounds like an efficient solution.

Thanks again for sharing your ideas.