Thanks for bringing this to my attention. I will work on duplicating the issue.
Am I right in assuming that you are using the ACF image field, and then wrapping the output in a filter hook to apply Picturefill.WP using code similar to the following?
In theme file:
<?php
$image_object = get_field('image');
$image_output = '<img src="' . $image_object['sizes']['medium'] . '" title="' . $image_object['title'] . '" alt="' . $image_object['alt'] . '" />';
echo apply_filters('theme_acf_image', $image_output, 'name_of_the_image_field');
?>
In functions.php:
add_filter('theme_acf_image', 'theme_function_for_acf_image', 10, 2);
function theme_function_for_acf_image($content, $name_of_the_image_field){
return Picturefill_WP::get_instance()->cache_picturefill_output($content, $name_of_the_image_field);
}
I will come back with more questions if I have trouble duplicating the issue, but will take a run at it this weekend and report back.
Thanks very much for reporting the issue.
Thread Starter
Hal
(@halburgissnet)
Thanks for having nice plugin!
Yes, acf image field type. And the code is as you’ve presented. Sounds good.
Quick update:
Isolated the problem. The proposed fix is at GitHub commit f9b505cdea7425b24711127918802dbce634caa4. Will test and push version 1.2.4 sometime tomorrow, if all goes well.
Detailed update:
The get_unadjusted_size method in the Picturefill.WP model was designed to account for images where the image size was adjusted, but did not account for instances where the image width and height was not declared. Unfortunately, it was not an error that was obvious until GitHub commit 6f884c1a9dcdb52a23426f0c04eede0070f230e2 removed some unnecessary output. The addition to the method with GitHub commit f9b505cdea7425b24711127918802dbce634caa4 should take care of the oversight.
Version 1.2.4 is on GitHub and if testing goes well, I plan on pushing an updated version to the plugin SVN sometime tomorrow.
I have just pushed update 1.2.4. I would appreciate hearing the effect it has on the issue, when you get a chance.
Thanks very much
Thread Starter
Hal
(@halburgissnet)
Sure thing! I see there is a 1.2.5 now on wordpress.org. Sadly, I am still seeing the same output, just one size being echoed:
<section class="entry-content clearfix slide">
<span data-id="slideimg" data-title="element-home-page-h-14" data-picture="">
<span data-src="http://test.loc/wp-content/uploads/2013/10/element-home-page-h-14-768x511.jpg">
<img id="slideimg" title="element-home-page-h-14" src="http://test.loc/wp-content/uploads/2013/10/element-home-page-h-14-768x511.jpg">
</span>
<noscript><img id="slideimg" src="http://test.loc/wp-content/uploads/2013/10/element-home-page-h-14-768x511.jpg" title="element-home-page-h-14" alt="" /></noscript>
</span>
This is a major bummer, but at least it’s not the same problem. With the previous output, it looked like the plugin was confused by the image width and as a result loading only the thumbnail. Now, it looks like the plugin isn’t recognizing the image attachment id and as a result outputing only the fallback image. The same way it would if the image src was from a different website.
I have a suspicion that my regular expression in the url_to_attachment_id method may be the troublemaker.
I expect to have some time to dedicate to this on Friday. I will report back as soon as I find something.
Thread Starter
Hal
(@halburgissnet)
Thank you sir! If anything I can do, let me know.
I am having difficulty duplicating the issue this time. As much as I would like to get this sorted, the recent Skipping Image Sizes issue deserves to be patched quickly.
If you don’t mind, try out the 1.2.6 update, and try a few different images with your ACF setup to see if the issue persists.
Since I’m having trouble duplicating, the next thing I will try is to put together some testing scripts to hook into the various methods and try to catch the trouble maker in the output. When I have them put together, I’ll post these for you to try, if you’re willing.
Thanks very much
Thread Starter
Hal
(@halburgissnet)
Yea, I’d be glad to. No problem whatsoever. In the meantime, I’ll try the latest release. Thanks.
Thread Starter
Hal
(@halburgissnet)
OK, quick update … tried a different image, with everything else the same, and that seemed to work! That was a dummy image. Tomorrow, I will go through and replace what’s there so far, and see if that gets us where we want to be. I’d still be curious to learn why the existing images aren’t working fully? Strange.
Also, on unrelated note, ACF allows images to be defined 3 ways. I would suggest adding to ACF documentation that images need to be declared as “Image Object”. That has all the size data.
Thread Starter
Hal
(@halburgissnet)
OK, deleted that image (again), and started over. All seems to work well now! We had done that at least once before so still curious what the difference is now. Thanks.
Thread Starter
Hal
(@halburgissnet)
OK figured it out! Its a WP gotcha with how images get uploaded and hardcoded with the uploader’s domain.
In our development model we have 3 environments and domains: local developer (eg example.loc), staging and production. Because of the WP practice of hardcoding domains, we typically try to only upload images during development via the staging site, or else they get tagged like example.loc/some.jpg, and thus are only visible to developers working locally. When uploaded to staging, they are visible to both environments. (Then when we go live we have to fix things).
I was able to readily reproduce the “partial output” scenario depending on what domain images are uploaded from. So for us, uploading to staging site works fine if site is then loaded from the staging url. But just get the partial output if the exact same code is viewed locally (example.loc).
I didn’t dig deep enough to see why picturefill.wp starts to build correct looking html, then seems to bails out, but I’m convinced that’s the root cause. FYI.
Good sleuthing. This makes sense to me. The partial output:
<section class="entry-content clearfix slide">
<span data-id="slideimg" data-title="element-home-page-h-14" data-picture="">
<span data-src="http://test.loc/wp-content/uploads/2013/10/element-home-page-h-14-768x511.jpg">
<img id="slideimg" title="element-home-page-h-14" src="http://test.loc/wp-content/uploads/2013/10/element-home-page-h-14-768x511.jpg">
</span>
<noscript><img id="slideimg" src="http://test.loc/wp-content/uploads/2013/10/element-home-page-h-14-768x511.jpg" title="element-home-page-h-14" alt="" /></noscript>
</span>
is what I would expect from an image referenced from an external url. It’s what is supposed to happen when Picturefill.WP cannot match the image url with a url in the guid column of the wp_posts database table. Without that attachment id, Picturefill.WP is unable to retrieve any information about alternate image sizes that may exist.
It might work if you export the rows from the wp_posts table where the post_type = attachment from the staging environment database and import them into the development environment database. But that might not be worth the trouble.
Thanks very much for the effort you’ve put in duplicating the issue and finding its source.
I have just pushed update 1.2.4. I would appreciate hearing the effect it has on the issue, when you get a chance.
Thanks very much
@remas2010,
I would encourage updating to the current version 1.2.6, as it addresses another non-trivial issue for HDPI screens.
Version 1.2.4 did indeed address the original issue of incorrect output caused by undeclared image width values.
The lingering issue discussed here is one of referencing images not saved to the database as post attachments.
Picturefill.WP cannot serve up HDPI or responsive versions of images that are not in the wp_posts table of the database, regardless of where they live on the server.
Do you feel like this answers your question?
