Switch between RSS content and Web page content (store both)

[danielyrovas]

• I have tested my changes
  • currently fails language test, as I added a line to the English language JSON file
• I read this document: https://miniflux.app/faq.html#pull-request

Please let me know what you think of this change.
It solves an issue that has irked me when using the interface, which is overwriting the original RSS content with the webpage content which sometimes is not as well formatted as the original RSS content or is empty/junk. It allows people to hit the download button just to see what the page looks like when it is downloaded, but still return to the RSS page to continue reading.

The feature works like this:
Whenever an entry is loaded, if there is downloaded content available, that will be displayed and the Download button becomes Show RSS Content.

Otherwise the page loads like normal, showing the Download button and the RSS page content.

If the Show RSS Content button is selected, the original RSS content is displayed and the button turns to the regular Download button.

If this Download button is selected, the page is processed and saved like normal (re-downloading it even if it has been saved before).

The /fetch-content API method now returns both content and web_content as JSON.

[danielyrovas]

This is problematic, I didn't look at how rewriter gets its data - I'll add a commit which fixes this.

[danielyrovas]

Rewriter now operates on web_content - as far as I can see rules do not operate on RSS content - only when processing original web page content.

[danielyrovas]

I merged the commits and rebased onto main.

[fguillot]

Looks like the unit tests are failing after your rebase

[danielyrovas]

Yeah, I'll need to change some of those tests I think. The TestRewriteWithYoutubeLink checks the Content field instead of the WebContent field. I imagine it is similar for the other failing ones.

[danielyrovas]

Hi @fguillot, I've updated my pull request. Do you mind taking a look at it?

[fguillot]

Why should the rewrite rules apply only to WebContent? They should apply to both Content and WebContent, especially for feeds that provide full HTML content by default.

[oldherl]

Any progress on this?

[wolfhechel]

This to me seems to be changing the way the current v1/fetch-content endpoint works. The expectation is that the returned content key will be the web content, as such it would be breaking compatibility with current clients such as my own.

Surely, such a change should be prefixed to a bumped version - otherwise, what's the point of the v1 prefix at all?

Also I don't see why fetch-content needs to be changed at all since the purpose of it is to return the web content. An easy solution would be to switch web_content to be content as before and return entry_content for the original content.

Clients are generally okay with additional API information, not so much with removed or changed.