Photo view — visual hero-image grid layout for image-rich events

[Salem874]

ELI5

The Events Calendar (TEC) has a "Photo view" — a poster-board grid of upcoming events that leads with the hero image. It's great for festivals, conferences, gallery openings, and ministry photo-ops. We already store hero/poster/profile images on every event — we just don't have a view that shows them off.

Detailed proposal

Add an 8th view mode photo to the calendar view picker alongside the seven shipped via #137/#138 (month, week, day, list, agenda, summary, map). Route: /calendar?view=photo (registered via AppRegistry calendar app view list). UI surface: a 3-column (≥md) / 4-column (≥xl) / 1-column (xs) responsive masonry grid of upcoming tblEvents rows, ordered by startAt ASC, default window = next 90 days, paginated 24/page.

Each card renders:

• Hero image (priority: tblEvents.heroImage → posterImage → profileImage → category-colour tile from tblEventCategories.colorHex)
• Title (linked to event detail)
• Date + time chip
• Venue chip from tblEvents.locationName
• Category colour swatch + name from tblEventCategories
• Event-type badge from tblEventTypes (worship / social / etc.)
• Series indicator from tblEventSeries when set
• RSVP count badge from tblEventRsvps when RSVP is enabled

Brand-aware: card chrome respects Site::branding() accent + radius tokens, same as the existing six new views.

No schema changes. No new tables. No new admin UI. One new view file (web/_apps/calendar/views/photo.php), one CSS block in portal.css (or calendar.css if extracted), one branch in the calendar router. Empty state for "no upcoming events with images" falls through to category-colour tiles so the grid never looks broken.

Pros / Cons

Pros

• Uses image columns that are already populated and otherwise underexposed
• High visual marketing value for festivals, fundraisers, gallery openings, ministry photo-ops
• Zero schema / migration risk — pure additive view
• Sits naturally in the existing seven-view picker — no new IA
• Plays well with brand layer (Multi-brand product layer (ChurchMS / SchoolMS sub-brands) on top of tenant branding #296) — sub-brands get the look for free

Cons

• Events without hero images fall back to colour tiles — mixed grids can look uneven
• Loading 24 hero images per page adds bandwidth — needs lazy-loading + responsive srcset
• Card height variance (masonry) needs testing on small viewports

How necessary?

Medium — high value for events/marketing-led orgs (churches running festivals, schools running open days, charities running galas); low value for admin-heavy installs.

Acceptance criteria

• view=photo registered as the 8th calendar view in the view picker
• Responsive masonry grid: 1 / 2 / 3 / 4 columns at xs / sm / md / xl
• Image priority order honoured; category-colour fallback tile when none
• Date, venue, category, event-type badges render on every card
• Lazy-loading + srcset for hero images; LCP ≤ 2.5s on 4G test
• Brand-aware chrome (accent + radius) matches the other six new views

Estimated effort

4–6 hours focused work.

---

Filed during The Events Calendar competitive analysis on 2026-06-16; decision pending.