Dennis looked at camhazzard.com and asked a simple question: with so many AI-generated sites out there now, doesn’t a homepage full of text-only blog cards just look like one more template? Most of these posts came from a real video conversation. Why isn’t the face from that video anywhere on the card? We agreed it should be, fixed it live on two sites, and along the way found (and fixed) a real bug in how Elementor 3.x saves new images.
The ask
Dennis: “There’s a section with cards for the latest few blog posts, and it’s just text. Most of these come from YouTube videos, so maybe we can include that. I feel like there are so many of these AI sites that, to make it look more human, we need to show actual pictures and videos of humans to make it more interesting.” The ask had three parts: fix camhazzard.com, then make it a standard across every personal-brand site, starting with harryjgold.com, nathanielstevens.com, dylan-haugen.com, and georgeleith.com.
camhazzard.com — done, verified live
camhazzard.com runs its whole homepage as a single Elementor 4.0.8 text-editor widget, so the “Latest reads” cards were three <a class="chh-card"> boxes with overflow:hidden already set. That made the negative-margin bleed technique a clean fit — the thumbnail bleeds to the card’s outer edge and gets clipped by the card’s own overflow. All three cards already had featured images (RankMath’s auto-generated YouTube overlay thumbnails), so no new image sourcing was needed. Saved via a raw REST postmeta write — Elementor 4.0.8 did not show the img-stripping bug described below. Cleared the Elementor cache and confirmed live.
Two of the three thumbnails now live on camhazzard.com’s homepage — real frames from the actual video conversations, not stock photography.
nathanielstevens.com — the bug that almost stopped the rollout
nathanielstevens.com builds its homepage from 13 native Elementor sections, and the “Latest Writing” cards live in a dedicated html widget (Elementor 3.34.2) with overflow:visible — the wrap-in-body-div pattern. All three featured pieces already had photos, so this was meant to be a straightforward apply-the-pattern job.
It wasn’t. Every raw REST write to _elementor_data saved correctly to the database — 200 responses, confirmed via authenticated context=edit reads — but the new <img> tags never appeared on the live front end. We tried removing every attribute one at a time (class, style, width/height, loading, decoding) and finally tested a completely bare <img src="…"> with nothing else on it. Still stripped. That ruled out any individual attribute as the cause.
Diagnosis: the raw REST/postmeta save bypasses Elementor’s own document pipeline entirely. Fix: open the real editor, find the widget’s Container object in elementor.documents.getCurrent().container, and push the identical HTML string through $e.run('document/elements/settings', ...) followed by $e.run('document/save/update'). Same content, different save path — and the images rendered immediately. This is now written up as the required method for any Elementor 3.x img edit — see the definitive article.
All three “Latest Writing” cards on nathanielstevens.com now render real photo thumbnails, confirmed via screenshot after the $e.run fix.
The other three sites: refreshed content, one down site, one N/A
dylan-haugen.com got the full treatment — the three featured cards were stale (Jan/Dec/Nov 2025, and one linked post had actually been deleted), so we refreshed to the three most recent published posts, generated two new featured images from their YouTube embeds, and rebuilt the cards with the wrap-in-body-div pattern. The content and links are live and correct. The thumbnails are not rendering yet — this site hit the same Elementor img-stripping bug, and the fix needs the $e.run method applied from inside the real editor, which requires an active WP-admin login we lost mid-session (no stored credentials to log back in). Nothing is broken for visitors — the homepage still shows its prior state until this is finished.
georgeleith.com turned out not to need this fix at all: its homepage has no “latest posts” card section in the first place. Its /blog/ archive already renders thumbnails natively through the theme’s post loop.
harryjgold.com is down entirely — the domain does not resolve (DNS NXDOMAIN, confirmed via direct lookup and in-browser). This is unrelated to the thumbnail work and is flagged separately below as its own urgent item.
What’s still open
- dylan-haugen.com — needs a fresh WP-admin login, then the same $e.run fix (already proven, ready to reuse) plus a re-clear of both the Elementor and WP Rocket caches.
- harryjgold.com — domain isn’t resolving at all. Needs Dennis or the registrar/DNS host to look at nameserver/delegation status; not something fixable from here.
- The remaining ~193-site fleet — the standard is now written up for every new build; backfilling existing sites is blocked on the same Application Password provisioning gap already tracked for the fleet.
The full standard — sourcing priority, both CSS techniques, the Elementor save-pipeline rule — is written up as a definitive article for every future build.

