Make WordPress Core

Opened 8 years ago

Closed 17 months ago

#35043 closed defect (bug) (wontfix)

Images in RSS feed are broken

Reported by: griffinjay's profile griffinjay Owned by: joemcgill's profile joemcgill
Milestone: Priority: normal
Severity: normal Version: 4.4
Component: Media Keywords: has-patch close
Focuses: Cc:

Description

After installing 4.4, there now appears to be a bug with images in the RSS feed. When I plug my feed into the validator at:
https://validator.w3.org/feed/

it says:

This feed is valid, but interoperability with the widest range of feed readers could be improved by implementing the following recommendations.

line 41, column 0: content:encoded should not contain srcset attribute

line 41, column 0: content:encoded should not contain sizes attribute

I noticed the problem of broken images in Mailchimp where I use the RSS-to-email template.

Attachments (1)

35043.patch (513 bytes) - added by SergeyBiryukov 8 years ago.

Download all attachments as: .zip

Change History (35)

#1 @SergeyBiryukov
8 years ago

  • Component changed from General to Media

#2 @SergeyBiryukov
8 years ago

  • Milestone changed from Awaiting Review to 4.4.1

#3 @joemcgill
8 years ago

  • Owner set to joemcgill
  • Status changed from new to reviewing

Thanks for opening a new ticket @griffinjay. Since the markup in the RSS feed is technically valid, I'm curious to know more about what exactly is breaking with your MailChimp emails. Could you share a URL to a broken email or a screenshot of what you're seeing on your end?

The code that I had shared on #34945 to manually turn off responsive images in your feeds was meant to be copied into your theme's functions.php file. I'm adding it again here for reference:

function no_responsive_image_feeds() {
    add_filter( 'max_srcset_image_width', function() {
       return 1;
    } );
}

add_action('rss2_head', 'no_responsive_image_feeds' );
add_action('atom_head', 'no_responsive_image_feeds' );
add_action('rss_head', 'no_responsive_image_feeds' );

#4 @griffinjay
8 years ago

Joe, the blog post with two photos is at:
http://trialstrainingcenter.com/now-open-registration-for-2016-trials-training-days/

Here's a link to a screenshot (with two of my arrows) showing what happens when Mailchimp grabs the RSS feed to prepare for embedding the blog post into an email newsletter:

http://trialstrainingcenter.com/wp-content/uploads/2015/12/TTC-mailchimp-broken-images.png

Does that help?

Last edited 8 years ago by griffinjay (previous) (diff)

#5 @griffinjay
8 years ago

Joe,

I installed this plugin:
https://wordpress.org/plugins/disable-responsive-images/

as described here:
https://wordpress.org/support/topic/is-it-possible-to-disable-the-responsive-image-srcset-on-wordpress-44

It didn't work initially but on the recommendation of my web host, I turned off the WP-Super Cache plugin and then resubmitted the feed to the validator and it came up clean.

And then I tested it with Mailchimp and it works.

So I'm going to trigger Mailchimp at 10 am today and then disable the plugin.

#6 @SergeyBiryukov
8 years ago

  • Keywords has-patch added

It looks like both https://validator.w3.org/feed/ and http://feedvalidator.org/ don't recognize the new srcset and sizes attributes in feeds.

I'm not sure if it qualifies as a bug, as the feed is still valid, and these notices are recommendations, not errors.

We could probably bail early from wp_make_content_images_responsive() if is_feed(), see 35043.patch.

Last edited 8 years ago by SergeyBiryukov (previous) (diff)

#7 @azaozz
8 years ago

  • Keywords commit added

Disabling srcset and sizes for feeds is the right thing to do imho. 35043.patch looks good.

#8 @dd32
8 years ago

I'm not sure I agree that disabling it for RSS feeds is the right thing to do. RSS feeds are designed to contain valid HTML, and if a reader doesn't understand the attributes, then they should either strip or ignore them in their parsing.. unless there's a spec specifically for the valid tags & attributes in RSS that I haven't yet found?

Looking at the screenshot of Mailchimp up there says that something is broken with their parser implementation, it might be rewriting the URLs or something. I'd be interested in seeing the actual underlying <img> tag that they generate before saying it's definitely a problem that we need to fix.

This ticket was mentioned in Slack in #feature-respimg by joemcgill. View the logs.


8 years ago

#10 @joemcgill
8 years ago

I tend to agree with @dd32 here. The validator shows that the feed is valid and leaving this as is will prompt people to update their parsers to take the new HTML attributes (which are part of the spec) into account. We have a documented workaround for sites who run into specific issues and need an escape hatch.

#11 @azaozz
8 years ago

I agree with @dd32 too. The thing is that we shouldn't be causing problems for the users while third party software is updated to support the current standards.

On the other hand if this is affecting only few users and the RSS readers/parsers are being updated, perhaps we should keep it as-is.

#12 @joemcgill
8 years ago

I've set up a RSS-to-Email campaign with MailChimp to test the original issue mentioned in this ticket and there are several interesting layers to keep in mind in this process.

First of all, the MailChimp screenshot posted by @griffinjay shows the email preview that is part of MailChimp's product web app. It looks like they're parsing all images in feeds and displaying them through a CloudFront proxy so they can show previews over a secure HTTPS connection. However, they are not proxying images in the srcset attribute, so those requests are being blocked by mixed content errors within the app.

However, once the email is sent, the choice of how to display those images is up to the client receiving the email. Apple's mail app displays the original HTML, including srcset and sizes but those attributes are effectively ignored by the HTML parser (or so it seems). Google Inbox parses the HTML and rewrites img tags entirely so sources can be proxied through their own secure network. Office 365, on the other hand, currently strips out srcset and sizes attributes, but serves the original image asset over HTTP.

In all cases I tested of RSS-to-email, the image was displayed in the email client without any breakage.

However, Feedly.com, a fairly popular RSS reader, seems to be choking on HTTP images requested via srcset attributes because of mixed content warnings, even though HTTP images requested via src attributes load just fine. Kind of odd.

Since responsive image markup included in feeds only seems to affect specific cases, I'm still inclined to leave it on by default as a way of encouraging third party software to take srcset attributes into account inside their apps. For anyone who needs to turn off responsive image support in their feeds, we have a documented workaround, which we could put into a standalone plugin if needed.

#13 follow-up: @jorbin
8 years ago

I'm a bit torn on this. On the one hand, we aren't breaking the RSS spec to the best of our knowledge, on the other we are a bit ahead of the curve with srcset compared to the majority of the internet. Is saying that products like Mailchimp and Feedly need to update, the bug is on there end, any different than if we said the bug is in IE8 and Microsoft should update it to fix it? Shouldn't we work everywhere that is reasonable?

Alternatively, does anyone have a contacts at Mailchimp/Feedly we could leverage to see if a fix could happen sooner rather than later?

#14 in reply to: ↑ 13 @dd32
8 years ago

Replying to jorbin:

Is saying that products like Mailchimp and Feedly need to update, the bug is on there end, any different than if we said the bug is in IE8 and Microsoft should update it to fix it? Shouldn't we work everywhere that is reasonable?

I would almost say it isn't any different, except we're dealing with a SAAS product that's actively maintained and can have fixes applied "easily".
If IE8 was a SAAS product which was actively maintained and used, which had bugs fixed in it often, then I would be hesitant to completely disable a feature for that browser too.

Alternatively, does anyone have a contacts at Mailchimp/Feedly we could leverage to see if a fix could happen sooner rather than later?

Has anyone here reported it to their support teams? It wasn't obvious how I could do that as a non-user of those products.

#15 follow-up: @joemcgill
8 years ago

I've reported the issue to both MailChimp and Feedly. I've gotten confirmation from Feedly that they're working on a fix. I would reiterate that it's only the previews and not the actual emails that are broken on MailChimp.

#16 in reply to: ↑ 15 ; follow-up: @griffinjay
8 years ago

Replying to joemcgill:

I've reported the issue to both MailChimp and Feedly. I've gotten confirmation from Feedly that they're working on a fix. I would reiterate that it's only the previews and not the actual emails that are broken on MailChimp.

Joe,

Mailchimp also has another preview feature that allows one to send out test emails. When I did that, the images were broken, too.

#17 in reply to: ↑ 16 ; follow-up: @joemcgill
8 years ago

  • Keywords commit removed

Replying to griffinjay:

Replying to joemcgill:

I've reported the issue to both MailChimp and Feedly. I've gotten confirmation from Feedly that they're working on a fix. I would reiterate that it's only the previews and not the actual emails that are broken on MailChimp.

Joe,

Mailchimp also has another preview feature that allows one to send out test emails. When I did that, the images were broken, too.

Thanks for the update @griffinjay. Could you tell me what email client your using when you see broken images in these preview emails?

#18 in reply to: ↑ 17 @griffinjay
8 years ago

Thanks for the update @griffinjay. Could you tell me what email client your using when you see broken images in these preview emails?

@joemcgill I was using Gmail.

This ticket was mentioned in Slack in #core by jorbin. View the logs.


8 years ago

#20 @joemcgill
8 years ago

  • Milestone 4.4.1 deleted

Thanks again @griffinjay. I'm unable to replicate this issue in Gmail myself, but maybe I've got something different happening on my end.

I want to keep this open in order to do some more broad range testing against other email clients, but am moving it out of the 4.4.1 milestone in the mean time.

#21 @dd32
8 years ago

  • Milestone set to 4.5

#22 @littler.chicken
8 years ago

Just wanted to add that I've been dealing with this issue as well. I'm a Feedly user, and am gradually seeing more WordPress feeds with missing images, as they update to 4.4. It seems to be a mixed content issue, from what I can determine on Feedly. MailChimp campaigns for which I am responsible seem to be unaffected.

I've also authored an RSS plugin which is on the repository, and because of what I've been seeing, for the time being, I'm quietly disabling srcset in feeds. I'm using a slightly different filter than what's mentioned above, just returning false for wp_calculate_image_srcset, which seems to do the job.

#23 @vesica
8 years ago

Hi, today I discovered the same error on one of my clients' sites, running WP 4.4.1. I happen to have this website syndicated to another one I publish for the arts community in our area, and I found it when I saw something odd in her feed settings. (her feed has published posts & images consistently to this aggregate blog for years until now) The feed was titled as if it were a comment feed (Homepage: Comments on: Blog); her feed runs through Feedburner, and when checking there I saw the same thing, so I ran it the original feed through the feedvalidator.org. It validates, but with two errors:
This feed is valid, but interoperability with the widest range of feed readers could be improved by implementing the following recommendations.

line 37, column 0: content:encoded should not contain srcset attribute (10 occurrences) [help]

<div id="attachment_1883" style="width: 650px" class="wp-caption aligncenter ...

line 37, column 0: content:encoded should not contain sizes attribute (10 occurrences) [help]

<div id="attachment_1883" style="width: 650px" class="wp-caption aligncenter ...

The thing is that this is preventing the images in her posts from being published at my aggregator site - aside from a few random images that display, they do not show up at all any more (here's her "column" at my art blog: http://blogs.soartists.com/ArtMatters/category/art-community-news/artist-posts/by-silvia-trujillo/). I also notice that the reach of her posts reported by Feedburner has dropped to nearly 0 since Dec 22. I hope this additional information will help you decide how best to deal with this issue. Of course we all want our feeds to travel to their endpoints intact, but we also want our images to be responsive.

I saw the thread that griffinjay started in the forum and one person made a plugin that would remove the srcset, but of course I also have the issue with the sizes attribute, which the search engines do want to see. I'm not sure if this plugin is the best solution for us, and not being sure what to do, I'd love to know the best way to deal with this for the moment. Thanks so much for all you do to make WordPress awesome!

#24 @joemcgill
8 years ago

  • Milestone changed from 4.5 to Future Release
  • Status changed from reviewing to accepted

It looks like Feedly has updated their app to handle mixed content errors caused by trying to serve non HTTP resources from a srcset attribute inside their HTTPS pages. As more applications that parse RSS feeds are updated to handle srcset attributes (which will need to happen regardless of what WordPress does), I'm of the opinion that we should leave things as they are.

For the time being, anyone affected by this issue can make use of the code snipped in comment #3 above to disable responsive images in their RSS feeds.

I'm going to leave this open so we can review the status of things during the next release, but punting from the 4.5 milestone.

#25 @joemcgill
8 years ago

  • Keywords close added

I haven't seen any new reports of this in 6 months. Thinking we may be ok to close as a wontfix and let affected users handle this with a filter when needed. Any seconds?

#26 @lgpref
8 years ago

  • Version 4.4 deleted

Dear @joemcgill - I just caught this ticket today (which you closed), because those of us that use MailChimp are still struggling with scrset issues. See this Support Forum thread from three months ago - https://wordpress.org/support/topic/images-appear-in-rss-feed-as-empty-boxes-or-broken-images/?replies=5 They suggest using the "Disable Responsive Images" plugin, which apparently stopped working with the 4.6 update.

Would your code snippet (as listed in Comment #3 here) still work in 4.6?

I do hope that this issue is kept as a live bug, and that it is considered for a release in the near future. Thanks for your consideration and all the work you do with Core.

To expand on this note: we are dismayed to find out that MailChimp is still having issues with showing images in browsers due to mixed content 9 months after 4.4's release. Example of currently broken images in MailChimp newsletters visible in a browser (not email). Published Sept 7 2016 using MailChimp, Avada 4.0.3 theme and WP 4.6 (images are visible in email when "insecure content" is accepted, but all 404 in all browsers.
http://us8.campaign-archive1.com/?u=7cd99b58103a512a93f24db5a&id=57a1480852

#27 @SergeyBiryukov
8 years ago

  • Version set to 4.4

#28 @joemcgill
8 years ago

Hi @lgpref,

Thank you for the feedback, this is exactly what I was looking for and why I marked this ticket as a candidate for being closed without actually closing it.

I did some more testing and it looks like MailChimp's campaign builder previews do indeed still suffer from this issue unfortunately, but the browser previews that users see (like the one you posted a link to) do not suffer from this problem.

Looking into the case you linked to however, is showing that the images in your preview aren't displaying because they don't actually exist on your server (i.e., 404 errors) rather than mixed content errors due to trying to server HTTP resources in an HTTPS context.

#29 @lgpref
8 years ago

thanks for looking, @joemcgill. It's even more baffling, because those images DO get created.
This is the experience I'm having with Outlook and browsers (on Win7, and in Outlook Web Client in IE and Chrome).

I will open the email from MailChimp.
The images are broken, but if I click to allow unsafe content, it shows the images.

If I come back to the email after closing my client on Windows7 (or to the web client after a browser refresh), the images are broken and will not show. (Here's the weird part). If I come back to the email a few minutes later, the images will appear!
This image is currently live on our web site:
http://library.cedarmill.org/wp-content/uploads/2016/08/Glassland-Pierce-opt-300x150.jpg

The same image URL is cited in the HTML of the *email* version of the newsletter, snippet pasted below. Note that there are no srcset references, and there is only one image src.:
<snippet from HTML - full source of page available in PDF if you are interested>


<h2 class="x_mc-toc-title" style="margin:0; padding:0; display:block; fontfamily:'
Trebuchet MS','Lucida Grande','Lucida Sans Unicode','Lucida
Sans',Tahoma,sans-serif; font-size:20px; font-style:normal; font-weight:normal;
line-height:125%; letter-spacing:-.75px; text-align:left; color:#404040!important">
<a href="redir.aspx?
C=JmyMX5QdREP2Xz1kzzS5rjghVJ7Ip5vTygiepDn3ZTHEEX5V1NjTCA..&amp;URL=http%3a%2f%2fcedarmill.us8.com%2ftrack%2fclick%3fu%3d7cd99b58103a512a93f24db5a%26id%3d8598429d7c%26e%3d916a7a9eff"
style="word-wrap:break-word; color:#005680; font-weight:normal; textdecoration:
none" target="_blank">Film
Club: Glassland</a></h2>
<img src="http://library.cedarmill.org/wp-content/uploads/2016/08/Glassland-Pierce-opt-300x150.jpg" class="x_attachment-medium x_size-medium x_wp-post-image" alt="Glassland Pierce opt" style="float:right; margin-left:5px; border:0; outline:none; text-decoration:none; height:auto!important" height="150" width="300" border="0">In the film Glassland, there is much that is painfully and hopelessly clear as John, a young man in his early 20’s, tries to save […]<br>
<a href="redir.aspx?C=jzgba8fNcfb789tyTUkw7nT795ZoIBGnpXAKmQ0PBTEEX5V1NjTCA..&amp;URL=http%3a%2f%2fcedarmill.us8.listmanage2.com%2ftrack%2fclick%3fu%3d7cd99b58103a512a93f24db5a%26id%3deaf22cf2e3%26e%3d916a7a9eff" style="word-wrap:break-word; color:#005680; font-weight:normal; textdecoration: none" target="_blank">Read on »</a><br>
<br>


In contrast, from what I can see, the browser version of the email has srcset references, and will not load the existing image, which is the "glassland" 300x150px image, live on our website. http://us8.campaign-archive1.com/?u=7cd99b58103a512a93f24db5a&id=dfc7b6bbce

This leads me to believe that it's true that MailChimp "fixed" the srcset issue in their email newsletters, but did not do anything to the "archive" (browser-based) versions, so RSS-to-email campaigns will still cause issues with WP responsive image handling. Am I making a correct connection here? This behavior is so distracting, when it works sometimes, and sometimes not, which makes it really hard to pin down.

My goal with this discussion is to determine where to fight this battle. There are so many fronts that are possible here; I'm hoping that your code snippet (changing WordPress rss feed formats) is the right direction. If not, I'm left to sort through a myriad of "fronts", including our theme developers (Avada/ Theme Fusion), MailChimp support, plugin developers for "Featured Images in RSS with Size", or to just give up on MailChimp entirely. Thanks for your advice, and let me know if you'd like any forwarded hardcopy of source files or emails from MailChimp for testing. Best wishes.

#30 @joemcgill
8 years ago

Hi @lgpref,

I definitely understand to frustration of trying to sort through several different possible causes for why something is broken on your website. In this case, I can tell you with some certainty that the issue is a result of your server returning "404 not found" errors for the images in question. First, the campaign browser link you've shared is not using HTTPS, so there is no reason to be concerned about serving non-HTTPS resources. The reason srcset is relevant is that when an image element contains a srcset attribute, modern browsers ignore the src value and choose one of the URLs listed in the srcset attribute.

For the markup of the image your referenced:

<img width="300" height="150" 
src="http://library.cedarmill.org/wp-content/uploads/2016/08/Glassland-Pierce-opt-300x150.jpg" 
class="attachment-medium size-medium wp-post-image" alt="Glassland Pierce opt" style="float: right; margin-left: 5px;" 
srcset="http://library.cedarmill.org/wp-content/uploads/2016/08/Glassland-Pierce-opt-150x75.jpg 150w, 
http://library.cedarmill.org/wp-content/uploads/2016/08/Glassland-Pierce-opt-200x100.jpg 200w, 
http://library.cedarmill.org/wp-content/uploads/2016/08/Glassland-Pierce-opt-300x150.jpg 300w, 
http://library.cedarmill.org/wp-content/uploads/2016/08/Glassland-Pierce-opt-400x200.jpg 400w, 
http://library.cedarmill.org/wp-content/uploads/2016/08/Glassland-Pierce-opt-540x272.jpg 540w, 
http://library.cedarmill.org/wp-content/uploads/2016/08/Glassland-Pierce-opt-600x300.jpg 600w, 
http://library.cedarmill.org/wp-content/uploads/2016/08/Glassland-Pierce-opt-768x384.jpg 768w, 
http://library.cedarmill.org/wp-content/uploads/2016/08/Glassland-Pierce-opt.jpg 800w"
sizes="(max-width: 300px) 100vw, 300px" border="0">

You're correct that the src image is found on your server, but on a retina device, the image requested will most likely be 2x the normal size — or in this case: http://library.cedarmill.org/wp-content/uploads/2016/08/Glassland-Pierce-opt-600x300.jpg — and that URL does return a 404.

If you open up the developer console in Chrome (or whichever browser you use) you will see something like this screenshot which shows the 404 errors instead of blocked insecure content warnings. I'm not sure why these images are not being found on your server, but the first thing to check would be to make sure those images files actually have not been removed. If so, you may need to use a plugin like Regenerate Thumbnails to rebuild those image files.

For more assistance, I would suggest opening a support request and referencing this ticket.

Hope that helps,
Joe

#31 @lgpref
8 years ago

thanks, again, joe. We'll continue working on this.
One note regarding your comments about the "missing" images:

The 404 images in the Console are referenced in the img tag> "srcset" section code.
However, if you view the Source and navigate to the individual image files cited in the Source display, those images are alive and well (and in addition, all the other responsive sizes are generated and live on the server, generated by our theme). So weird.

So, this seems to point to a srcset conflict which MailChimp has not addressed in their browser preview layout, which is quite unfortunate for those of us that like to refer users to archived newsletters or those that want to view one in their browser. Our images are safe, even though the internet doesn't think they are ;-)https://www.dropbox.com/s/izvrgi1gmiyznpv/rss-images-dont-load-when-srcset-is-used.jpg.

We will explore options of altering/disabling the srcset/responsive image options in our RSS feeds in the short term, and complain to MailChimp about it. I'll keep an eye on this thread to see if anything else develops on the WP Core side. Thanks much.

#32 @littler.chicken
8 years ago

I have an RSS plugin in the repository and have disabled srcset on all images due to Feedly issues (for sites without SSL certificates, which I believe have been fixed at this point), as well as some of the recently mentioned issues. You might try using:

<?php
add_filter( 'wp_calculate_image_srcset', '__return_false' );

in your feed output to disable srcset in your feeds altogether, until MailChimp has resolved the issue to your satisfaction. This has worked for me. (It's added within a function which has already checked for the feed, so if you don't have something similar, you'd need to flesh it out to apply it conditionally to your feed.)

#33 @lgpref
8 years ago

Thanks @littler.chicken and @joemcgill : we'll work on implementing her plugin/fix and see if that helps us in the short term. However, I do wonder if we are having issues with the Sizes attribute instead/in addition (like @vesica reported 8 months ago) since it says "max-width=300"; would that conflict with the use of a retina 2x image? Sigh. Thanks again.

Last edited 8 years ago by lgpref (previous) (diff)

#34 @JeffPaul
17 months ago

  • Resolution set to wontfix
  • Status changed from accepted to closed
Note: See TracTickets for help on using tickets.