Pictures not shown in some feeds with figure block

Tiny Tiny RSS Support
1

I have a problem where images in figure blocks don’t show up, but images in paragraph blocks do.

IFor example at Gizmodo that there’s an image. With curl on the command line I can download the image, so I don’t think it’s a certificate problem on my server, or a the remote side rejecting based on referrer or browser ID.

When the article shows up in my feed, instead of having the image at the correct spot, it has

<figure>
  <div>
     <div></div>
     <figcaption>Image: DC Comics.</figcaption>
  </div>
</figure>

When I look at a feed where the image is working, it’s in a

<p>...</p>

or a

<span>...</span>

with the expected

<img src="https://myserver/hash=...png"...>

Is this the problem? If so, what can I do about it?

I’ve tried with and without readability, and with and without image caching. I have af_feedmod and feediron enabled, but I have the problem on feeds that don’t pass through them.

This is on the current git master, running on a Debian stable system with php5, or whatever is included. It very well could be a local problem, but I don’t know where to start looking.

2

tt-rss does not arbitrarily modify feed XML (unless you ask it to), whatever you see was in the feed already, which is something that you can easily check via myfeedsucks

If so, what can I do about it?

you can make a plugin to rewrite that markup out of the feed, i guess

also: gawker feeds being broken has been reported multiple times before (see old forum)

3

Yeah, I’d been assuming it was the Gawker stuff being broken, as usual, but maybe Univision has a good web department? The feed checks fine on myfeedsucks, and shows me what I expect to see in TT-RSS.

One entry on the feed starts like this

<figure class="js_marquee-assetfigure align--bleed"style="max-width:1280px;">
<div class="img-wrapper lazy-image "><div class="img-permalink-sub-wrapper" style="padding-bottom: 56.3%"><picture><source class="ls-small-media-source"data-srcset="https://i.kinja-img.com/gawker-media/image/upload/s--8hkfk
]]>
<![CDATA[
Utz--/c_scale,fl_progressive,q_80,w_800/l1dxgoh9ssxpyu6awsj5.jpg"media="--small" />
<source data-srcset="https://i.kinja-img.com/gawker-media/image/upload/s--8hkfkUtz--/c_scale,fl_progressive,q_80,w_800/l1dxgoh9ssxpyu6awsj5.jpg" media="--xlarge" />
<source data-srcset="https://i.kinja-img.com/gawker-media/image/upload/s--8hkfkUtz--/c_scale,fl_progressive,q_80,w_800/l1dxgoh9ssxpyu6awsj5.jpg" />
<img src="https://i.kinja-img.com/gawker-media/image/upload/s--8hkfkUtz--/c_scale,fl_progressive,q_80,w_800/l1dxgoh9ssxpyu6awsj5.jpg" class="lazyload ls-lazy-image-tag" data-sizes="auto"data-chomp-id="l1dxgoh9ssxpyu6awsj5" data-format="jpg" />
</picture></div><figcaption>Image: AP</figcaption></div></figure>

However that image never shows up in TT-RSS. I would think that the <img src=… stuff at the bottom would be enough.

I’ve disabled more plugins. Maybe one of them is doing something I’m not expecting.

4

I’m seeing the same behavior from all univision/gawker feeds. No difference with all plugins disabled. It’s just them messing with their CMS again, probably.

5

@Jeff,

The code doesn’t look well formed. And given all the problems people report with the site, I’m not surprised. Like mentioned, you could code a plugin to clean it up but it really doesn’t seem worth it given how frequently they break things.

6

@JustAMacUser,
Thanks for this. My idea of html is a few

<li>

blocks, so I can’t tell if that is valid code.

It’s only a snippet, so if it only looks broken because it doesn’t end correctly, then it’s probably just that I truncated it. If there’s stuff in the middle that looks broken, then it probably really is broken. Though as I said, myfeedsucks thought it was fine.

7

I’m on my mobile so it’s tough to see the whole excerpt or write a lot here… but I think the HTML would pass validation, but there’s the CDATA in the middle of an attribute. Multiple, custom data attributes for images, a srcset attribute and yet no simple src attribute–which should be there as a fallback. So yeah, those are the kind of things a validator might miss but you as a user would notice.

No doubt the exact same code is used on their site proper and with some accompanying JavaScript adjusts the DOM to give you the best quality pic. But just that plain code is less reliable in an RSS feed.

8

fwiw broken markup is out of the question because everything goes through libxml which would just refuse parsing broken content. if it parses, it’s technically valid xml.

9

I was just saying it’s more about the fact that they’re using custom data selectors and have no actual src attribute to fall back on. Without their accompanying JavaScript there’s nothing to pick an actual image from their data attributes so TT-RSS correctly renders the HTML… which as it is specifies no image to show.

10

ah, right, if they do something like that i guess readability or a custom plugin is the only way.

11

The images are not showing up because TT-RSS filters out the <picture> tag. When I added the <picture> tag to the allowed_elements array in include/functions.php the images came back.

12

picture tag? what fresh hell is this

some idiot in whatwg: what if we introduce another image tag because clearly there’s not enough markup to go around
everyone else: applause

13

HTML is moving on, grandpa… :stuck_out_tongue: I suggest you get on with it… :wink:

14

surprisingly relevant for so many reasons

15

I added this as a quick fix to my plugin: GitHub - nowotny/ttrss-fix_gawker_embeds: Tiny Tiny RSS plugin that fixes the broken embeds in various Gawker feeds

16

definitely the right stuff for an rss feed content which is going to be displayed in an unspecified third party program

with bonus “we had img srcset but we decided it was not convoluted enough so welp here’s another tag (which contains other new tags)”