robbevp/feed-reader

README

This README would normally document whatever steps are necessary to get the application up and running.

Things you may want to cover:

• Ruby version

• System dependencies

• Configuration

• Database creation

• Database initialization

• How to run the test suite

• Services (job queues, cache servers, search engines, etc.)

• Deployment instructions

• ...

feed-reader's Issues

`mail.received` can be a direct field or an array

In NewsletterMailbox we assume that mail.received returns an array.

In some cases, this can return a single field, resulting in the following error:

undefined method `first' for #<Mail::ReceivedField:0x00007f0a775b0e18 ...> (NoMethodError)

Updating a subscription with RssFeed as subscribable will create a new RssFeed

To reproduce:

• Create a subscription with RssFeed
• Edit some field (name or category) in the subscription
• Save
• A new RssFeed is created and the old one is not cleaned up

Only fetch image once accross all entries

We currently fetch each image url once per entry.
Since some images are used accross multiple entries, we might want to limit data usage (and the amount of work we have to do, by only fetching each image once).

Some good example of images that are reused are:

• logos/icons in mailchimp newsletter: these are often the same accross all emails
• the bandcamp logo: this is the same image in all emails that bandcamp sends

Automatically mark entry as read when user reaches bottom of entry show

When a user has seen the whole entry (because it is very short, or they scrolled to the end), the entry should automatically be marked as read.
This should be indicated to the user with a quick notification
If a user puts the entry back to unread, this action shpuld not fire again

Add links to next/previes entry at bottom of entry page

This next/previous should use the currently saved scope (unread, category,...)

Rss feeds that recurringly return errors should warn the user

Remove tracking pixels from entries

Some entries will contain tracking pixels, like:

<img src="some_url" width="1" height="1" style="display: none;" />

We should try to detect these tracking pixels, and remove them from the entry's body.

Proxy images inside inline styles

Some entries will have images in inline styles (using background:, background-image: or content:). We should also proxy these images
Some entries might also have these properties using inline styles, we should also proxy these.

Proxy images found in scrset

Some entries will contain links to images using srcset. This can be done in two ways:

• <img srcset="..." />
• <picture><source srcset="..." /></picture>
  (or a combination of the two).

We should also proxy these images.

Allow user to delete individual entries

While it does not make sense for most entries, in some specific cases a user might want/need to delete a specific entry. We should enable this.

This case comes up when a user subscribes to a newsletter and receives a confirm subscription email

Allow user to add a category to a subscription

Proxy images inside entries

For reliability / reduced tracking, we should:

• Detect all images inside entries
• Download them and store them on the sever
• Modify the entry to use our proxied images

Distinguish long and short entries

Based on the word count inside a post, we should try and categorise entries.
For example:

• Short (200 words or less)
• Medium
• Long

Store search params accross nagivation

If a user searches on the homepage, then navigates to an entry, and the goes back to the homepage, the search params are lost.

We should store the search params somewhere (a cookie? in the url?), so that a user always returns to the homepage with their current search

Make sure links inside an entry body open in parent window (or new tab)