Photon: Auto-generate additional srcset options#3748
Conversation
|
This looks great! I just tested this and it appears to be working as expected on images that are inserted into a post. It doesn't seem to be handling custom crops though. For example, I have 80x80 images on my sidebar, and the images are distorted because they aren't being cropped anymore:
The auto-generation is awesome, but if we wanted more control would it be possible to output our own srcset sources? |
|
@ChrisBegley - Thanks for the testing and feedback. I believe you're right that I need to add checking to make sure the srcset proportions match the proportions of the original image if we're going to include it. The commit I just pushed does not include that yet.
Right now, with the PR as it stands, you can use Core's filter before priority 10 to amend the srcset values that Core natively provides, then use the filter in the PR to "short-circuit" the auto-creation. |
|
In 1494174 : Add a sizes array filterOriginal patch props @aduth Since we've been debating this point back and forth, you can disable this filter by adding a If the content_width is not set, we are using the original Core behavior for now. We can/should add another maximum, but I ran out of time today. srcset improvementsIf there is a content_width set, we will attempt to generate srcset values of 2x and 3x content_width, assuming that'll cover the maximum displayed size on the vast majority of HiDPI devices. (Need to test: What happens when using a 3.5x or 4x device? Does it still grab the full size? Is that okay) If there is no content_width, we'll generate a few options at 80%, 60%, and 40% of the original image size. Testing neededStill needs a ton of testing, not ready for merge. Just to keep the conversation moving. |
class.photon.php
Outdated
|
|
||
| // Responsive image srcset substitution | ||
| add_filter( 'wp_calculate_image_srcset', array( $this, 'filter_srcset_array' ), 10, 4 ); | ||
| if ( ! has_filter( 'wp_calculate_image_sizes') ) { // To allow themes to fully control the sizes array. |
There was a problem hiding this comment.
Could we achieve the same effect by setting a lower priority to our filter, since if a theme had defined their own, it would be run and filtered later (assuming default priority of 10)?
There was a problem hiding this comment.
I'm open to it. I don't have strong opinions on how we do it, as long as we let theme authors be smarter than we can be globally. I'm trying to think what kind of use case would modifying it before a theme gets it would cause problems; nothing yet.
|
@ChrisBegley can you provide detailed steps on how to reproduce ( and make sure that you are using the current version of the patch ). I've tried out cropped images ( via image edit in wp-admin ) in posts and so far they appear normal. If there is something we are missing I want to make sure that we get reproduced so we can address it. |
|
I think I have it duplicated. Used this in a plugin/theme functions: then inserted the "Kraft Hard Crop" image via wp-admin. The resulting srcset include hard resize Photon args from the core produced sizes (as expected) while the new ones from this PR are soft-cropped, e.g. |
|
@josephscott oops, I think I misunderstood what @kraftbj meant by "custom crops". I haven't tried inserting images that I cropped with WordPress into posts. I was referring to custom thumbnail images that I have in my theme that use crops. Like this:
|
|
@ChrisBegley that makes sense, when I saw "crop" my mind when immediately to the crop tool in the image editor of wp-admin. Just so I make sure I've got all of this right, with this patch you end up with http://i1.wp.com/techyourworld.com/wordpress/wp-content/uploads/2014/02/Superman-Man-of-Steel-Logo-Imgur.jpeg?resize=80%2C80 - what does pre-patch crop version look like? Sorry, it is the http://i1.wp.com/techyourworld.com/wordpress/wp-content/uploads/2014/02/Superman-Man-of-Steel-Logo-Imgur.jpeg?w=576 URLs using the |
|
@josephscott yes, that's exactly right. Pre-patch it was using So I used to get this: Now I get something like this: It's no longer being resized and cropped to the dimensions defined in my theme: |
|
0ef8a63 provides some support for hard-cropped image sizes. @ChrisBegley, can you give it a whirl? We probably still need to add checks, across the board, to not insert a srcset that is bigger than the full-size image. At this point, Photon will return the original size image in those cases, but not ideal. (Updated for a new SHA. Left some debug code in previously) |
9934d41 to
0ef8a63
Compare
|
@kraftbj looks great on my end! It automatically added in 2x and 3x versions too, which is awesome. Let me know if there's anything else you want me to take a look at. |
|
Thanks @ChrisBegley! I added a check to make sure we're not adding entries larger than the full width image. Before, it was doing things like for an original image size of 150x150: Now, it'll abort for any variants where the new size is larger than the original, based on width. |
|
Marking this for 4.0.4 as this behavior is a bug (making Photon less performant than previously). |
|
Made 2 minor changes, but otherwise this looks good to merge to me (and @kraftbj told me it was okay :) ) |
|
Do we want to squash this down until a couple of atomic commits? |
|
Squashing would be great, @kraftbj -- also, Travis needs to pass :) |
244e972 to
888af95
Compare
888af95 to
aa59aef
Compare
|
Squashed, rebased against master to pick up Travis improvements (this PR was still running the double-set of Travis builds). No tests were failing, just cancelled them due to yesterday's Travis backlog. Will merge/cherry-pick once tests pass. |
Photon: Auto-generate additional srcset options
WIP
See #2918