Problem
Every Open Graph / social share image renders at 1200×630 (~1.91:1) while the underlying crop boxes are a different aspect ratio (news 5:3, member/person 1:1, project 5:3). Because the OG render aspect ≠ the crop aspect, easy_thumbnails applies a second center-crop on the editor's box — so a Facebook/Twitter/LinkedIn/Slack preview can clip people's heads even when the on-page image looks fine.
Render sites:
website/templates/website/news_item.html:51 — news OG 1200x630website/templates/website/project.html:73 — project OG 1200x630website/templates/website/member.html:59 — member OG 1200x630
Why this isn't a one-line fix
A single stored crop box cannot be WYSIWYG for both the on-page render and a 1.91:1 social card — and 1200×630 is the platform standard (social sites also re-crop to ~1.91:1 on their end regardless of what we send). Simply rendering the OG at 5:3 would just move the clipping to the platform.
Options to discuss
- Dedicated social crop field — add a separate
ImageRatioField at ~1.91:1 (og_cropping) so editors compose the social card explicitly. Most correct, most work (model + admin widget + migration considerations; note the gitignored per-env migrations).
- Accept it — keep
1200×630, document that social previews may center-crop. (Current de facto behavior.)
- Smarter default — generate the OG from the full image (or a face-aware crop) rather than the on-page crop box.
Invariant (for reference)
Any {% thumbnail X box=Y.cropping ... crop %} must use Y's crop aspect ratio; only pixel size may vary — otherwise easy_thumbnails re-crops. OG is the one place this is intentionally violated (documented exception in website/tests/test_news_crop_aspect.py).
Context: found while fixing the news-image head-clipping bug (branch news-crop-aspect-mismatch, v2.26.1).
Problem
Every Open Graph / social share image renders at 1200×630 (~1.91:1) while the underlying crop boxes are a different aspect ratio (news 5:3, member/person 1:1, project 5:3). Because the OG render aspect ≠ the crop aspect,
easy_thumbnailsapplies a second center-crop on the editor's box — so a Facebook/Twitter/LinkedIn/Slack preview can clip people's heads even when the on-page image looks fine.Render sites:
website/templates/website/news_item.html:51— news OG1200x630website/templates/website/project.html:73— project OG1200x630website/templates/website/member.html:59— member OG1200x630Why this isn't a one-line fix
A single stored crop box cannot be WYSIWYG for both the on-page render and a 1.91:1 social card — and
1200×630is the platform standard (social sites also re-crop to ~1.91:1 on their end regardless of what we send). Simply rendering the OG at 5:3 would just move the clipping to the platform.Options to discuss
ImageRatioFieldat ~1.91:1 (og_cropping) so editors compose the social card explicitly. Most correct, most work (model + admin widget + migration considerations; note the gitignored per-env migrations).1200×630, document that social previews may center-crop. (Current de facto behavior.)Invariant (for reference)
Any
{% thumbnail X box=Y.cropping ... crop %}must useY's crop aspect ratio; only pixel size may vary — otherwise easy_thumbnails re-crops. OG is the one place this is intentionally violated (documented exception inwebsite/tests/test_news_crop_aspect.py).Context: found while fixing the news-image head-clipping bug (branch
news-crop-aspect-mismatch, v2.26.1).