Social Card upgrade - Part 1 #2090
Conversation
This will be used by social_previews to convert the templates into images. Setup a fallback image primarily for local dev, so that this won't cause errors if authentication is missing. Caching is setup to use contents of the html/css. So it with autobust/generate a new image whenever the markup changes.
+ Being random breaks caching (since we generate cachekey by a SHA of html content) + Use Roboto for when generating via HTML/CSS to Image
+ Make rand deterministic so it doesn't break caching
When adding .png to the url, these routes will now generate an image and redirect to it. This leaves the existing pages as they were, so we're backwards compatible with all the existing links out in the world.
|
|
| @@ -1,28 +1,65 @@ | |||
| class SocialPreviewsController < ApplicationController | |||
| # No authorization required for entirely public controller | |||
|
|
|||
| PNG_CSS = "body { transform: scale(0.3); } .preview-div-wrapper { overflow: unset; margin: 5vw; }".freeze | |||
There was a problem hiding this comment.
Filling the entire viewport results in a ~4000x4000 pixel image. Scaling it down makes rendering way faster.
|
I've added keys to the prod site, still on the free plan, and can upgrade when ready. I'm curious about the right path forward will be for the migration so that we might not need to re-generate all the existing generated images where possible. There's a day one issue where we'd need to re-generate all the images as they are ingested by Twitter/FB bots etc. It's not the end of the world, but there could be a long-tail of unique images. Haven't fully thought it through. |
|
@benhalpern 🙌. I think best option would be to set a "migration" DateTime inside the object/service that gives back the og:image url. Then WDYT? ^ |
This is a follow up to part 1: forem#2090. This PR updates the og:image URLs to use the new social_preview.png urls added in Part 1. So that the already generated/cached images do not need to be recreated, this sets a MIGRATION_DATETIME. Any object that has been updated after that date will generate a new image Objects from before that date will not. They will use the new url.
* Social Cards Part 2 This is a follow up to part 1: #2090. This PR updates the og:image URLs to use the new social_preview.png urls added in Part 1. So that the already generated/cached images do not need to be recreated, this sets a MIGRATION_DATETIME. Any object that has been updated after that date will generate a new image Objects from before that date will not. They will use the new url. * Fix weird change made by rubocop autocorrect * Handle organizations + users * Run CI * Use time with zone to be explicit about timezone * Simplify branching in user_social_image_url method * Fix param alignment + bump migration date
Dev.to + HTML/CSS to Image ⚡️
👋 @benhalpern
This gives the
SocialPreviewsControllerthe ability to renderpng's.Current URL:
https://res.cloudinary.com/practicaldev/image/url2png/s--pncSBGoq--/c_fill,g_north,h_400,w_800/https://dev.to/social_previews/article/75561%3Fbust%3D0-Build%20a%20GitHub%20Action%20with%20Ruby-true"Future:
https://dev.to/social_previews/article/89948.pngFancy Gif
Backwards compatible
Implemented this so that this PR is a no-risk deploy. Nothing is breaking. All the old URLs work exactly the same as before. The social_preview routes now also support
.png.How does caching work?
The rendered html is used as the cache key (Dalli SHAs it). This means, we get cache busting "for free", the cache will bust whenever the template changes, or the data included in the template (such as article title or user's name) updates.
To do this, I had to remove some of the randomness in the templates. They are now "deterministically random", meaning the object's ID is used as the seed. So you get the same sequence of random numbers each time.
Release Plan
HCTI_API_USER_IDandHCTI_API_KEYenv variables.What type of PR is this? (check all applicable)
Mobile & Desktop Screenshots/Recordings (if there are UI changes)
(https://hcti.io/v1/image/e632881d-b0f6-4d33-be3f-a5863cf260a2)
(https://hcti.io/v1/image/7455df4e-636e-4bed-b0f6-90cb419977fb)
(https://hcti.io/v1/image/6c52de9d-4d37-4008-80f8-67155589e1a1)
Added to documentation?