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.
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)
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.
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.
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.
@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.
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.
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.
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.
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.