List of Google Drive links getting parsed as embeds

[TylerFisher]

Weird edge case on our embed parsing. In this doc, Lisa put a list of Google Drive folder links in an unordered list. Our parser thinks they're supposed to be embeds, and it comes across as an unsupported embed in the published version.

In the doc:

In the published story:

I thought the easiest way to solve this would be to just add some text to each bullet item that isn't linked (e.g. Link: Ang Diaryo. But when I tried that, no links at all came across, just underlined text.

So there's a few ways to go about this:

1. No list item should ever be interpreted as an embed. I can't imagine a reason to do that.
2. Links that have text that isn't the URL should also never be embeds.
3. If we find an "embed" that doesn't match our regex of accepted URLs, we should just display them as links. It made sense for us in testing to do the "is not supported yet" thing, but not anymore I think.

[jacqui]

@TylerFisher I had a look at the code around embeds and I think the issue here is actually a bit simpler: the code for detecting embeds in the Google Docs add-on parser does not match the code for displaying embeds in the front-end.

The frontend supports the following types of embeds:

• Twitter
• Facebook
• YouTube
• TikTok
• Instagram
• Spotify
• Apple Podcast

The parser in the add-on supports a wide range of platforms and does so by matching the URL - google.com is one of the regex matches.

I think these two lists of supported platforms should match - we don't really want to display "xyz is not supported yet" on the published sites, right?

For a quick fix though, until we can discuss this issue in real time, I will remove "google.com" from the list of "embed" urls and test out publishing an article.