Describe the bug

Under #1153 we added skip links to all pages in the app. A skip link should be the first element focused on a page when the user presses the Tab key - however, this is only the case in a Forem if you land directly on a URL, and not if you navigate internally, e.g. by a link click.

There are several strategies available to managing focus on route change, but I would suggested the approach Marcy Sutton has written about following user testing with Fable: What we learned from user testing of accessible client-side routing techniques with Fable Tech Labs

The recommendation in that article is to send focus immediately to the skip link on the new page. We will need to experiment with :focus-visible to ensure that for users who navigated by mouse click, the skip link isn't visible. If this isn't possible, I think an acceptable fallback would be to focus an empty element directly before the skip link, so that once on the new page, the skip link is the first item focused on Tab press.

To Reproduce

• Load the home page, and press Tab. You should see the skip link appear
• Activate the skip link by clicking or pressing Enter
• Select a post using the Tab key and press enter to view it
• On the new page, press Tab again
• Notice that the skip link is not the first item focused, and if you want to get to the main post content you have to press Tab multiple more times

Expected behavior

• I select an article by keyboard on the home page
• On the new page the skip link is visible and focused
• If I repeat these actions but use the mouse, the skip link is not visible when I arrive on the new page

Describe the bug

The modal triggered by the three dots on the left of an article appears stuck under the navbar of the website, it is not readable entirely.

To Reproduce

After submitting an article but before publishing. Click on the three dots on the top left of the article. The modal will show up but a part of it is hidden behind the navbar

Expected behavior

The modal should appear entirely to see all the links. It can appear under the navbar, or on top of it.

Screenshots

Desktop (please complete the following information):

• OS, version: MacOS Catalina 10.15.7
• Browser, version: Chrome Version 88.0.4324.192 (Official Build) (x86_64)

Additional context button id="article-show-more-button"

Describe the bug

When using the podcast liquid tag in an article the button that should have "Follow" no longer displays the text. I tested this with several podcasts and none of them display the "Follow" text.

To Reproduce

1. Navigate to the editor to create a new post.
2. Use the podcast liquid tag to render any of the podcasts on DEV {% podcast url-for-episode-here %}
3. click preview to preview the liquid tag
4. Scroll down to the rendered podcast liquid tag; it will be displayed with an empty button that should contain "Follow"

Expected behavior Follow text inside of the empty button

Screenshots

Here you can see the text is not rendered at all in the HTML

processed_html for recent podcast episodes is nil.... The body which is the raw content returned from the RSS, is present. So something is wrong with our pipeline.

Example...

https://dev.to/devdiscuss/s1-e6-little-known-productivity-tools-big-productivity-gains

While importing from RSS, if the time is set to approximately current (for example it's 22:00 UTC, and date: is getting set to 21:57), dev.to deployment won't accept the post.

A significant reduction in time should be applied for the post to be posted. For example, 20:57 UTC shall work.

Expected behaviour: dev.to deployment accepts the post.

Post in question: https://dev.to/doma/parser-combinators-in-rust-1f2e

A 10 second summary: https://www.youtube.com/watch?v=4ddiTSWtwB8

To Reproduce

1. Go to dev.to/settings/extensions
2. Enter RSS feed like https://doma.dev/atom.xml
3. Click Save Feed Settings
4. Choose a post to publish, for example "Parser combinators in Rust"
5. Click "Edit"
6. Change time to current minus three minutes, make sure to keep the time zone intact
7. Click "Save"
8. Get confusing error actually advertising wrong time format!
9. Change the time to current minus one hour and three minutes, make sure to keep the time zone intact
10. Click "Save"
11. Now the post saves, even though both attempts were valid

Expected behavior

Expected behaviour: dev.to deployment accepts the post when we click "Save" the first time.

Screenshots

https://www.youtube.com/watch?v=4ddiTSWtwB8

Desktop (please complete the following information):

• OS, version: Linux, Windows
• Browser, version: Firefox

Smartphone (please complete the following information):

• Device: NAN
• OS, version: NAN
• Browser, version: NAN

Additional context

Ditto

Describe the bug

Each tag has an associated taggings_count which contains the number of items they are associated with (in our case either articles or listings).

The problem lies in the fact that some of these counts are incorrect in the DB.

I found this out by playing with the Tags API which returns tags sorted by taggings_count in descending order

For example:

1. archlinux according to the API - https://dev.to/api/tags - is the third most used tag but it's very unlikely that is true. Its tag page - https://dev.to/t/archlinux - lists 50 articles and even taking into account all listings it might have been used in, it doesn't add up
2. https://dev.to/api/tags?per_page=15 shows that devops is more popular than showdev but devops page contains 2917 articles, showdev page contains 3110. Again, I don't think there are enough listings tagged with devops to account for the difference

Thus, the bug.

This counter is managed by automatically by the acts-as-taggable-on gem.

Expected behavior

I'd expect the counter to reflect the correct number of items that have been tagged with it.

I see two possible explanations:

1. there's an error in our setup, in respect to the usage guide
2. it has something to do with tag aliasing (?)
3. there's a bug in the gem itself. I found a few issue tickets that might point us in this direction:

• https://github.com/mbleigh/acts-as-taggable-on/issues/929
• https://github.com/mbleigh/acts-as-taggable-on/issues/947

Currently we user surrogate keys to determine when certain endpoints should have their caches cleared, such as an article API endpoint like this...

set_surrogate_key_header Article.table_key, @articles.map(&:record_key)

And then we call article.purge which magically makes any endpoint with that article's record_key have its edge cache expire.

More on surrogate keys...

https://docs.fastly.com/en/guides/getting-started-with-surrogate-keys

The issue with the above logic is that a new article which should become part of that endpoint will not flush its cache if created. So it will not show up on that endpoint until another article which fits within the above @articles is purged. This makes it kind of random to find out when it will be included.

article.purge is a magic method to create a purge ping which uses the appropriate surrogate header.

A solution for this could be a surrogate key like this...

set_surrogate_key_header Article.table_key, "tag-index-endpoint-#{tag}", @articles.map(&:record_key)

and then we make a specific purge call when a new article should purge it like purge("tag-index-endpoint-#{tag}" when an article is created.

Our current situation isn't causing any radically wrong behavior and the "random" purging is working okay but we should look into this as we go about bigger changes here.