Hi, I am not sure what happened but gallery rss feed no longer shows images. Tried different PCs, browsers, feedburner, nothing. Just titles and descriptions. Source code shows the image link, etc. as it did before. Is there a setting for this or something?
If the image is shown in the source, then there's not much that should go wrong. Have you got an example feed URL?
Our RSS feeds are still not showing images.. one of the plugins we use to display images, the developer says the RSS feed does not use standard image tag. Is this something xenforo team can address? Add standard image tag to the rss feeds for xmg so its easier for external sources to pick up the image?
The HTML we use in the feed is perfectly valid HTML. Can your developer explain why they believe it isn't valid? At the moment I can only guess what he's referring to, but one thought is that the order of the attributes on the img tag may be not be as expected by their application. If you're happy to try something, this might give us some more answers. Edit the template xengallery_rss_content and find: HTML: <img alt="{$media.filename}" src="{xen:link 'canonical:xengallery/full', $media, 'd={$media.last_edit_date}'}" title="{$media.media_title}" height="{$media.height}" width="{$media.width}" /> And replace with: HTML: <img src="{xen:link 'canonical:xengallery/full', $media, 'd={$media.last_edit_date}'}" alt="{$media.filename}" title="{$media.media_title}" height="{$media.height}" width="{$media.width}" /> (The src attribute has swapped positions with the alt attribute). Let me know if that makes a difference.
That did not help, sorry. This is what I've got in the xengallery_rss_content: Code: <span></span> <p> <xen:if is="{$media.media_type} == 'image_upload'"> <a href="{xen:link 'canonical:xengallery', $media}"><img src="{xen:helper fullurl, $media.thumbnailUrl, true}" alt="{$media.filename}" title="{$media.media_title}" height="190px" width="290px" /></a> <xen:else /> {xen:raw $media.videoHtml} </xen:if> </p> <xen:if is="{$media.media_description}"> <p> <i>{$media.media_description}</i> </p> </xen:if> <br /> I also reverted the template and tried, no luck. thank you
I'll look into this a bit more. I am seeing a similar issue with Firefox RSS feeds, but there's no logic to why it would work with some and not others. I'll move to bugs for now, bear with us while we look into it.
I've figured this out. If you consider this feed entry: HTML: <item> <title>Kaczor-donald</title> <description><![CDATA[test]]></description> <pubDate>Fri, 01 Jan 2016 02:09:22 +0000</pubDate> <link>https://xenforo.com/community/media/kaczor-donald.1195/</link> <guid>https://xenforo.com/community/media/kaczor-donald.1195/</guid> <author>invalid@example.com (webbo)</author> <dc:creator>webbo</dc:creator> <content:encoded><![CDATA[<span></span> <p> <a href="https://xenforo.com/community/media/kaczor-donald.1195/"> <img src="https://xenforo.com/community/data/xengallery/125/125278-7914063bc5f69d8b1d05b36d397a1c13.jpg" alt="kaczor-donald.jpg" title="Kaczor-donald" width="300" height="300" /> </a> </p> <p> <i>test</i> </p> <br />]]></content:encoded> </item> Notice the HTML in the "content:encoded" tag. It certainly appears to be valid (and it is). However all that displays in the actual RSS feed is the word "test". One would assume this is coming from the bit at the bottom of the content (which is the media description) but it's not coming from there; it's coming from the "description" tag. This was tested in Firefox. So, if Firefox sees a "description" tag, it uses that instead of the "content" tag. From what I can see, different RSS clients behave differently with this, though they all seem to consistently support the content tag, so I've made some changes here. We no longer attempt to populate the description tag, therefore the problem no longer crops up. I'm also fairly unhappy with how the feed parses (with it using full size images) and there was another bug here anyway with regards to video thumbnails so I have taken the opportunity here to only display thumbnails now and this should equate to an overall nicer looking output. Thanks for your patience with this. Ultimately it was down to client quirks, but I'm glad we could make a change easily enough to sort it.
