Describe the bug While using Strikethrough markdown within link text, I discovered the strikethrough is not rendered in live comment views only; this appears to work elsewhere (comment previews, posts, and post previews).

To Reproduce

Add strikethrough text within a link to a comment:

[~~strikethrough~~](https://www.example.com)

This looks fine in posts, post previews, and comment previews:

...but not in a submitted comment:

Expected behavior

Strikethrough markdown within link text is rendered correctly.

Desktop (please complete the following information):

• OS, version: Fedora Core 33
• Browser, version: Firefox 88.0.1 and Chromium 91.0.4472.77

Describe the bug In issue #13935, @andygeorge reported that strikethrough text within links was rendered as normal text in live comments. I found out that the method shorten_urls in models/comment.rb was causing the issue and raised PR #14103 fixing it. However, I later discovered that no text formatting (bold, italics etc) is rendered within link text in comments.

To Reproduce Add text formatting within link text in comments:

[__bold-text__](https://www.example.com)
[~~strikethrough~~](https://www.example.com)
[_italic_](https://www.example.com)
[___bold-italic___](https://www.example.com)

This looks fine in posts and comment previews:

But isn't rendered in comments (Only strikethrough works because #14103 got merged):

Expected behavior Text within links should be formatted correctly in comments.

Desktop (please complete the following information):

• OS, version: POP_OS! 20.10
• Browser, version: Firefox

Additional context

The bug occurs because shorten_urls in models/comment.rb strips out all html tags within anchor tag in the html text processed from markdown. The method is used to truncate URLs longer than ~37 characters.

In my opinion, the best way to fix this issue is to limit shorten_urls to only truncate URLs and not custom link text. Doing so will also prevent any useful text from getting truncated.

potential bug: comment preview looks different from the final comment, because URLs aren't shortened in previews. This could be raised as another issue.

@jgaskins I was worried about the unexpected bugs, and it appears that a bug has occurred :( . Images in the comments don't get rendered as images but as plain links. E.g ![Alt-text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/q2czbn344eli58gs3ln6.png) gets rendered as -

Images were working fine when I tested it on local, but that would be because localhost urls are structured differently. I am extremely sorry about this, should've tested it thoroughly. I'll fix it as soon as possible. In the mean time, the changes should best be reverted.

Update: I have fixed the bug. Shall I revert the changes and create a new PR? Again, apologies for the inconvenience ?

If two people share the same RSS Feed URL in Settings -> Publishing to DEV Community from RSS Then new post will appear randomly only in 1 feed.

1. Have two separated dev.to accounts
2. Go to Settings -> Publishing to DEV Community from RSS and setup the same RSS Feed URL in both
3. Create a new RSS entry
4. The entry is show in one of the two dev.to account's (say account A) Dashboard and not in the other (account B)
5. If the account who doesn't see the RSS feed (account B) tries creating a new post mentioning the new entry's canonical_url it gets a message canonical_url: has already been taken
6. If the account who does see the RSS entry (account A) deletes the draft, then Account B can publish successfully the content

Expected behavior

Both dev.to accounts should see the new RSS entry in the dashboard

Screenshots

Desktop (please complete the following information):

• OS, version: MacOS Big Sur 11.2.3
• Browser, version: tried with Safari, Chrome and Firefox

Smartphone (please complete the following information):

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

Additional context

tl;dr : I played around with two dev accounts and based on my observations, some issues will occur regardless of whether we fix this issue or not. My observations might be incorrect, correct me if I'm wrong.

Going through the PRs mentioned by @rhymes helped a lot. It's quite obvious now why canonical_url needs to be unique. I played around with importing from the same RSS feed from two dev accounts and this is what I observed:

• If an article from the feed was already imported in one account A, it won't be imported in account B regardless of whether the canonical_url was set or not, or if it was draft/published.
• If the article is deleted from account A, it can be fetched in account B.

Note: These observations are from using the Fetch feed now button, and not from periodic feed imports. I can think of following issues that will occur:

If we allow both accounts to fetch the same article:

• None of them gets to publish the post if the canonical_url is same. They can be published by changing it, but since there is no way to know which account is using it, the canonical_url might remain unused.

If we allow only one account to fetch an article (as is the case right now):

• There's a UX issue where user won't know why articles aren't being fetched from the feed.
• Articles are being fetched on first come first serve basis, which defeats the purpose of allowing 2 accounts to import from the same feed.

What type of PR is this? (check all applicable)

• [x] Optimization

Description

Currently, for articles and collections, the user uploaded images persist in the database, even after the article/collection using that image is deleted. This PR adds the functions required to delete user uploaded images (to cloudinary) in the article if any.

Related Tickets & Documents

Resolves #13936

Added/updated tests?

• [x] Yes

What type of PR is this? (check all applicable)

• [x] Bug Fix

Description

• In reference to issue #12486, I raised a PR #14298 which focused on deleting article edge cache when tags are updated, so that the new tag colors maybe reflected. The issue however was not the client side cache, it was the server side cache key view-helper-#{tag} that stores the colors of the tag. Deleting the cache at that key solves the issue.

Related Tickets & Documents

• Resolves #12486
• https://github.com/forem/forem/blob/de852bd466ef418ac07a6317de4af6f8b892338d/app/helpers/application_helper.rb#L89

Added/updated tests?

• [x] No, and this is why: This was a one line fix and is already tested by spec/models/tag_spec.rb:119

What gif best describes this PR or how it makes you feel?

What type of PR is this? (check all applicable)

• [x] Bug Fix

Description

• As discussed in #14291, there was an bug with rendering the organizations logo while featuring sponsors in the homefeed. While inspecting, I found that the same issue exists in /sponsors page as well. This PR fixes the bug.

Related Tickets & Documents

• Resolves #14291

QA Instructions, Screenshots, Recordings

Added/updated tests?

• [x] No, and this is why: a fallback has been added (profile image of org is displayed if they haven't uploaded a logo) and tests for the same aren't needed. Thought I should add tests anyway but realized that I won't be able to because of how the image uploader works.

What gif best describes this PR or how it makes you feel?

happy bug smashin everyone!

Currently, StoriesController has a lot of responsibilities, such as:

• rendering homepage
• rendering articles by tag
• articles by time
• articles search
• article page
• user profile
• user comments page
• organization page
• podcast episode page
• podcast episodes list

These responsibilities should be separated and placed into their own controllers because:

• the code would be easier to understand
• easier to debug
• easier to reason about performance

Approach

Ideally we want to take each of the responsibilities this single controller has right now and break them off into their own controller with their own route. I would imagine the workflow would go something like

• Add new route for supporting new url (ie /users/:id/comments)
• Replace existing links all over the codebase
• Investigate: what happens with legacy url? should we remove or support it?
• Take into account that these urls could be bookmarked or shared through social media by many users. should we support legacy url and redirect to new url ??

I've started doing some work on it, e.g. reorganized the views (#1584, #1317), but most of the work needs to be done. It seems like a big non-urgent task to consider doing. I suppose, that rails route constraints can be used to deal with the routes.