Replace embedded tweets #3869
Replace embedded tweets #3869
Conversation
During the Jekyll era, we used a Ruby oEmbed library to display tweets inline. This commit replaces tweet-embedding functionality, permanently caching all retrieved tweets. This commit: - Removes the unused Ruby plugin - Removes placeholder oembed tags from filters/configuration - Adds an 11ty Twitter embed plugin - Adds permanent tweet caching - Changes all posts with embedded tweets to use new syntax (just the URL) - Incidentally removes a stray README which was getting incorrectly pulled into the asset pipeline
| @@ -0,0 +1 @@ | |||
| [{"0ce81ce23a2491fe0e6fe7a76d2d95":"1"},{"cachedAt":1718212425058,"type":"2"},"json"] | |||
There was a problem hiding this comment.
I don't understand what the .cache is for, can you please clarify?
There was a problem hiding this comment.
Yes! The cache is preventing the site from pinging the Twitter to fetch the data every time we run a build. It stores all the tweet request/response data, and I've set it to cache permanently, so once we have the tweet, we should never need an external connection to get it again.
This is also going to save us a lot of ZScaler headaches.
There was a problem hiding this comment.
OK! Sensible, but does that necessarily follow that we have to update the cache ourselves? Or is the .cache a directory we can git ignore going forward and trust that the build has the updated data?
There was a problem hiding this comment.
I mean, I'm thinking we don't need to see the updated twitter feed ourselves while doing local dev?
There was a problem hiding this comment.
does that necessarily follow that we have to update the cache ourselves?
we don't need to see the updated twitter feed ourselves while doing local dev?
Neither of those questions squares with my understanding of how this caching works, so let me try to explain my understanding and get us on the same page.
About four of our blog posts embed tweets in them, as part of the narrative of the post. Here's a good example.
To get these tweets, we have to interact with one of the Twitter APIs. Previously this was done through an oembed gem. It doesn't look like that gem had any caching, so I think every time you ran jekyll build it hit the network and re-requested the tweet data.
The 11ty twitter plugin fetches tweets in blog posts one time, then caches the network data, then uses that cached data in the templates. There's no need for additional network requests to request a resource that's, for our purposes, immutable. Moncef isn't going to update his tweet from 2014 about a hack night. (I'd be open to reducing the cache length to 1 year or 6 months, though, to account for the possibility of account deletion.)
Let's say we add a new blog post that embeds a few tweets. When the person adding that post builds the site, it will request the new tweets, cache the data, and that's it — it's part of the blog, no need for anyone else to have to make the same requests.
Keeping the cache in the repo solves a lot of problems; .gitignoreing the cache creates headaches:
| Keep the cache | .gitignore the cache |
|---|---|
| No additional network dependency in CI | Dependency on Twitter API for every CI build |
| ZScaler issues only when tweets are added (rare) | ZScaler issues for every new contributor and for every new git clone |
Only users adding tweets will need to deal with sudo permissions or local certs |
All contributors will need to deal with these things |
| High dev-prod parity: what you see in local dev is what you see in production | If Twitter API is down or network issues happen during prod build, tweets will go missing |
If we .gitignore the .cache then every new contributor and every CI build will have to re-download the tweet data and deal with zscaler; by keeping the cache, we can avoid all of this.
And if new contributors all have to fetch the tweet data, it means a lot more of this kind of exchange:
"can someone help me figure out this certificate error?"
"oh that's zscaler, temporarily disable zscaler or get these certs"
"how do i do that?"
"sudo etc."
"I don't have sudo permissions yet"
"oh ok here's how to get them"
[ work is blocked a few days, or permanently if we can't justify them having sudo permissons ]
I suspect the permissions to temporarily disable zscaler may be revoked at some point, so I'd like the design of the solution here to minimize that workaround.
There was a problem hiding this comment.
Gotcha. Yes, I misunderstood the usage of the embed plugin -- this is for explicitly embedded tweets in posts. SGTM
Pull request summary
Replaces embedded tweets with 11ty library
Closes #3867