First Monday Journal

Although I fixed this problem by changing the URL, I think it’s interesting to point out which one works and which one doesn’t.

This one did NOT work: View of Formalizing and Securing Relationships on Public Networks | First Monday

This one worked: First Monday: Formalizing and Securing Relationships on Public Networks

Thank you for this great product. This is the first time I encounter a case it didn’t work the first time, in many years, which is quite a feat in my opinion.

@naitoon That site uses a very ugly structure. I am not an html expert, but I would not believe that this is or should be standard html.

The result of your first link does not contain any content directly, it only contains an <iframe> which embeds the content of your second link.

Article content from /download path is wrapped in <blockquote> which is ugly for use e.g. in wallabag. Don’t know how it would look in P2K with blockquotes.

I fixed both problems. Please try again and report, if it is ok now or not.

@HolgerAusB thank you.

I just retried and I still observe the exact same issue. I verified that I have version 2.6.6 on the extension, which is the last according to the Chrome Web Store.

Awkward! When I paste the URL directly into the form on the P2K website it works. When I am using the plugin I get no result, too. Usually that is vice versa on problematic sites.

But now that I think about it, it seems logical to me that the browser content is not working because of the embedded <iframe>, or am I wrong @fivefilters?

@naitoon: When using the plugin and seeing an empty preview → Click on Edit and deactivate ‘Use browser-retrieved content’

grafik

For other websites it is always a good idea to try it the other way around.

1 Like

@HolgerAusB that works. Deactivating “Use browser-retrieved content” results in the content displaying properly in the FiveFilters preview. Thank you!

Thanks for reporting this @naitoon and thanks for the fix @HolgerAusB!

I think you’re right. I need to look to see what happens when a content sent via the extension is treated and there’s a single_page_link that matches too. My guesses at the moment:

  • We ignore the single_page_link directive when the content is provided via the Push to Kindle extension
  • …or we don’t ignore it, but the extension is not sending the <iframe> element along when it fetches the final browser-rendered HTML.