Make blogs rss feed in Feedly shows glossary tooltips inline

[marv51]

Not sure if this is the right place for this ticket, hope someone can direct it to the right place at least.

I follow make.wordpress.org/core via RSS from feedly (feedly.com). Feedly shows the glossary terms explanation inline, making it almost unreadable. (see screenshot)

I have verified that the RSS feed does not contain the glossary, so Feedly must load the text directly from the site. Also the blog content is shown correctly in Firefox reader-view.

Feedly should really be the one to fix this, however, as it is a popular service maybe someone could find a way to even better hide the glossary tooltips?

[marv51]

Screenshot showing the issue

[Otto42]

This seems very much like a Feedly problem, because we specifically do not include the glossary info in the feeds, so without knowing where they pull their data from, it's a shot in the dark.

Report the issue to feedly.

[marv51]

Completely agreed. My free account does not seem to allow to contact support, so I tried tweeting at them.

I looked into this a bit further to see how other services work:

• Instapaper has same issue
• Safari reader view (both iPhone and iPad) only shows the "Welcome!" message.
• Microsoft Edge immersive reader mode does not show glossary content (but broken in other ways).
• Pocket works

[jeremyfelt]

I can reproduce this by adding the full URL of the Make core post to my Feedly "Read later" list, which (I think) scrapes page content rather than uses the RSS feed. I have no idea how Feedly is triggering the hover to include the text, but I'm not sure what could be done on the wp.org side to avoid it.

My RSS feed subscription in Feedly to Make/core does not show the glossary information.

I would attribute this to the issues that page scrapers see when trying to normalize content.

[marv51]

Thank you everyone for considering this. It does indeed look like reporting this to Feedly has resulted in a fix on their side.

That still leaves Instapaper and Safari reader view not working, but main problem is fixed.

Thanks!

Source:
@feedly Any chance you could look at this feedly bug? https://meta.trac.wordpress.org/ticket/5533
​https://twitter.com/marv51/status/1336232986619105286?s=20

@marv51 It's now fixed, thanks for reporting it.
​https://twitter.com/olivierzol/status/1336824253878992898?s=20

[TimoTijhof]

I'm encountering the same issue in FreshRSS and NetNewsWire.

I do not believe the problem is with Feedly, rather the issue is in the feed produced by the blog, which really does contain this content.

• FreshRSS 1.18.1
• NetNewsWire 6.0.2

[TimoTijhof]

It looks like this may be caused by WordPress (or at least the theme/plugin used by make.wordpress.org) outputting these blocks into content sent to WebSub. Which is missing the theme layout and script/styles needed for these blocks to make sense.

I would expect WebSub subscribers to instead be sent the same "clean" HTML as what is output via RSS.

This affects feed readers such as FreshRSS which auto-discover websub from the Atom feed, and then use that instead of the RSS content for new articles going forward.

<atom:link rel='hub' href='https://make.wordpress.org/core/?pushpress=hub'/>

Some details downstream at ​https://github.com/FreshRSS/FreshRSS/issues/4302.

[dd32]

Replying to TimoTijhof:

It looks like this may be caused by WordPress (or at least the theme/plugin used by make.wordpress.org) outputting these blocks into content sent to WebSub. Which is missing the theme layout and script/styles needed for these blocks to make sense.

I would expect WebSub subscribers to instead be sent the same "clean" HTML as what is output via RSS.

Ah, WebSub (via the PuSHPress plugin) makes sense here.

These aren't considered to be feeds to WordPress, as it renders the RSS feed outside of a RSS context, without specifying it's a feed.

I think this needs to be fixed in the plugin, which I'll take a look into
​https://plugins.trac.wordpress.org/browser/pushpress/trunk/send-ping.php#L39

[dd32]

Submitted this upstream to PuSHPress: ​https://github.com/Automattic/pushpress/issues/13

[dd32]

Replying to dd32:

Submitted this upstream to PuSHPress: ​https://github.com/Automattic/pushpress/issues/13

I've deployed the fix I've suggested for this upstream, onto WordPress.org.

Can others let me know if this seems to resolve it?

[coffee2code]

Closing this as fixed.

As already mentioned, an upstream fix had been released, there have been no follow-up comments here to otherwise refute the fix, and most especially a ​follow-up comment by TimoTijhof (the person who reopened this ticket) to the upstream issue confirms that the fix works.