Render related-project sidebar thumbnails at the Project crop ratio (#1416)

[eastagiletracker]

This PR proposes rendering the related-projects sidebar thumbnail at the Project.cropping aspect ratio so the editor's crop box is no longer silently re-cropped, and generalizing the crop-ratio guard test from news images to every cropped image in the templates (Fixes #1416). We include this PR work along with a full history of your repo at https://eastagiletracker.com/projects/233. You can sign in with your GitHub ID to claim ownership of the project.

What was wrong

website/templates/website/project.html rendered the related-projects sidebar thumbnail at 160x90 (16:9) while Project.cropping is an ImageRatioField locked to PROJECT_THUMBNAIL_SIZE = 500x300 (5:3). Because crop_corners applies the editor's box first and easy_thumbnails' scale_and_crop then forces the target ratio, the chosen crop got a second center-crop — trimming its top and bottom, exactly the class of defect the news detail render (750x350) hit.

Reproduced on master at 8a43c0f4 by driving your own processor chain in the project's container, with the top and bottom edges of the editor's box painted red and blue so anything trimmed is visible:

$ docker run --rm --network mlw-net -v "$PWD":/code -e DJANGO_ENV=DEBUG -e DATABASE_HOST=db \
    -w /code makelab_image python - < repro_crop.py
Project.cropping ImageRatioField = 500x300 (aspect 1.6667)
editor's crop box   = [0, 100, 1000, 700] -> 1000x600 (aspect 1.6667)
after crop_corners  = (1000, 600)

render 160x90 (aspect 1.7778) -> (160, 90)
  top edge pixel    = (255, 251, 251)   bottom edge pixel = (251, 251, 255)
  vertical share of the editor's box that survives = 93.8%
  editor's crop box preserved: NO -- trimmed by a second center-crop

render 160x96 (aspect 1.6667) -> (160, 96)
  top edge pixel    = (255, 0, 0)   bottom edge pixel = (0, 0, 255)
  vertical share of the editor's box that survives = 100.0%
  editor's crop box preserved: YES

So 6.25% of the height an editor deliberately framed never reached the page, and the admin preview gave no hint of it.

The change

160x90 becomes 160x96 — same width, 5:3, no model change and no re-cropping of existing content, as the issue proposes. .project-sidebar-related-thumbnail is width: 80px; height: auto, so the rendered box is 3 CSS pixels taller and nothing else in the sidebar moves.

website/tests/test_news_crop_aspect.py becomes website/tests/test_crop_aspect.py and now enforces the invariant for every crop field rather than only news — the issue's "consider generalizing it to project renders too". Three things changed in it:

• Renders are matched by their box= expression, and each expression maps to the model field that defines its ratio (Project.cropping, Person.easter_egg_crop, Sponsor.icon_cropping, ...). The ratio is read off the ImageRatioField itself, so changing PROJECT_THUMBNAIL_SIZE can never leave the test asserting a stale number.
• A completeness check fails if a template crops against a box the test does not know about, so a new render cannot be silently skipped. It immediately earned its keep: it surfaced member.person.easter_egg_crop in display_person_snippet.html, which nothing had been checking. It renders at 245x245 against a 245x245 crop, so it is correct — it just was not covered.
• CropProcessorTests pins the pixel-level behavior the rule exists to prevent, running the real crop_corners → scale_and_crop chain and asserting a 5:3 box survives a 160x96 render intact and loses both edges at 160x90. That turns the template scan from a convention into something the suite proves.

The 1200x630 Open Graph exception is unchanged and now cross-references #1417.

How I verified it

python manage.py test website --settings=makeabilitylab.settings_test was run on a clean checkout of master at 8a43c0f4 and again on this branch, each against its own postgres:16. Identical outcomes: 767 tests before, 770 after (the three added here), with the same two failures in test_backup_status.AdminBackupWarningTests in both runs — they want the backup-status volume the compose stack mounts, so they are unrelated to this change and were already red. Nothing new went red.

The new coverage is genuinely load-bearing in both directions. With the template left at 160x90, the generalized guard fails and names the render:

FAIL: test_crop_renders_match_their_crop_aspect
AssertionError: ["  website/project.html: 160x90 (ratio 1.778) != Project.cropping ratio 1.667 (500x300)
    {% thumbnail related_project.gallery_image '160x90' box=related_project.cropping crop=True upscale=True %}"]

and with 160x96 in place all five tests in the module pass. The only image on the page whose bytes change is the related-projects thumbnail; everything else renders exactly as before.

One thing I deliberately left alone: ML_WEBSITE_VERSION is untouched, since cutting the release is yours to time.

How this was managed

This work was tracked on a board imported from this repository's own issues and pull requests — 1322 stories and 51 labels — with the fix carried by the imported #1416 story: Related-project thumbnail on project page clips the crop. The full board is at https://eastagiletracker.com/projects/233.

If you'd rather not receive contributions like this, reply no-more-prs on this pull request and we won't open any further ones on your repositories.

---

Lawrence W. Sinclair
CEO / East Agile
linkedin.com/in/lwsinclair/
eastagile.com