by
A real photo helps readers see who or what an article is about. This guide helps website teams add that photo to each article card. Start with an image that fits the story, then check the live card.
This guide is part of How to QA a Personal Brand Website. Next, explore Article guidelines (how we write, and how your agent should), or Personal Branding: How to Build a Digital Presence That Proves Your Expertise.
Where this task fits in the Content Factory
This task belongs in Post. Its inputs come from the linked work below; its checked result becomes the next worker’s starting point.
1. ProduceCapture real work
2. ProcessTurn sources into useful assets
THIS TASK3. PostPublish and connect approved assets
4. PromoteShare proven work and measure results
Start, finish, and next step
- Start when
- An existing homepage article card lacks a relevant real thumbnail.
- Have ready
- Affected homepage and its card markup
- Post featured images or source video frames
- Correct editor/save rail and site access
- Follow the steps
- Choose an existing featured image, real video frame, or real photo
- Inspect the card’s actual overflow and use the matching layout
- Preserve existing markup while adding the image
- Save through the working builder pipeline
- Verify the anonymous published result
Use the detailed instructions in this article for each step.
- Finish with
- Article cards with meaningful real thumbnails that render on the public homepage.
- Measure the result
- Each card retains its text and destination
- Images load in the published page
- The chosen layout preserves readable card content
- Elementor edits use its working save path when required
- Hand off next
- Include the checked card pattern in the build checklist and record the affected pages in the run article.
Reference material for the inputs
Open this article’s tasks in the Task Library (our directory of tasks and recipes; see current Task Library). The library connects the current recipe, its smaller tasks, and the records of work performed.
Close the learning loop. Write a meta article: the record of this execution with the starting state, recipe version, result, checks, failures, and next owner. Link it back to this recipe and register the run under the same Task Library task. Reuse one execution ID for revisions and retries. A partial or failed run stays labeled that way. Public release follows the recorded publication authority; writing the run record is part of doing the task. Writing and revising that record belong to the original execution; they do not start another meta-article task. Use the findings to propose and verify a recipe improvement. See how recipes and execution records work together.
The sites reviewed in the original July 5, 2026 account had a section for the latest few articles — and the inspected article cards were pure text. A headline, a date, an excerpt, a “Read post” link. No face. No frame from the video the article came from. Just words on a card, which is exactly what a template generator produces and exactly what a real human doesn’t. This is the fix, the standard, and the bug we found while shipping it.
0
New photoshoots needed — thumbnails are pulled from existing featured images or the source YouTube video
2
Sites reported shipped and visually checked in that July 2026 pass: camhazzard.com, nathanielstevens.com
1
Silent Elementor bug found and fixed along the way — new <img> tags were vanishing from the live render
The problem: text-only cards read as machine-made
Dennis put it plainly looking at camhazzard.com: there are so many AI-generated sites now that a homepage full of clean headline-and-excerpt cards, with zero photos or faces, reads as generic rather than human — even when a real 20-year-old dunker wrote every word of it. Most of these articles started life as a real conversation on video: an interview, a talk, a call with Dennis. The proof-of-human was sitting right there in the YouTube upload. It just never made it onto the card.
The fix isn’t cosmetic. A thumbnail is the fastest signal a visitor (or a crawling model) has that a real person exists behind the text. It also does the ordinary job a thumbnail always did — it gives someone a reason to click the third card instead of just the first.
The standard: every card gets a real photo, sourced in this order
| Priority | Source | Notes |
|---|---|---|
| 1 | Post already has a featured image | Check the post’s actual featured-media field and rendered image. If a plugin supplied a thumbnail, verify its enabled edition/settings and the real result; an embedded video alone does not prove an image was generated. Use the existing image only when it is a clear, relevant real photo or frame. |
| 2 | Pull the frame straight from YouTube | Browser-side fetch('https://i.ytimg.com/vi/<id>/maxresdefault.jpg'), fall back to hqdefault.jpg if the first image is missing, too small for the card, a placeholder, or the wrong subject. Check response status, decoded dimensions and the actual depicted frame; byte size alone is not an image-validity test. Upload via POST /wp-json/wp/v2/media, then PATCH the post’s featured_media. Keep the image binary out of model text. Use the supported media upload route, preserve the source and verify the returned media ID and actual displayed image. |
| 3 | Real photo, last resort | If there was no video, use a real photo of the person/subject. Never a stock image, never a generated illustration — the entire point is proof of a human. |
Two layouts, depending on your card’s CSS
The July 2026 examples used padded cards in a grid. Inspect the current card structure and computed styles before applying either layout below; the card’s own overflow property decides which technique bolts a thumbnail on cleanly.
| Card has | Technique | How |
|---|---|---|
overflow:hidden | Negative-margin bleed | Insert the image as the card’s first child, pull it to the card’s outer edges with margin:-Ypx -Xpx 4px -Xpx (matching the card’s own padding), give it top-corner border-radius matching the card, and let the card’s existing overflow:hidden do the clipping. Used on camhazzard.com. |
overflow:visible | Wrap-in-body-div (recommended default) | Move every existing child into a new .card-body div, move the card’s original padding onto that div, set the card itself to padding:0;overflow:hidden, then prepend a full-width <img style="aspect-ratio:16/9;object-fit:cover;"> before the body div. This is the default layout to consider for a new build; check its actual spacing, links and image crop in that site’s desktop and mobile render. Used on nathanielstevens.com and dylan-haugen.com. |
The bug: new <img> tags can silently vanish from Elementor’s live render
What we saw
On two different Elementor 3.x sites (3.32.3 and 3.34.2, one with WP Rocket caching and one without, one editing a text-editor widget and one editing an html widget), writing new <img> tags directly into _elementor_data via a raw POST /wp-json/wp/v2/pages/<id> saved to the database every time (verified 200 responses and raw context=edit reads) — but the images never rendered on the live front end. We ruled out caching, widget type, and every individual <img> attribute (class, style, width/height, loading, decoding) one at a time. A completely bare <img src="…"> with zero other attributes still got stripped.
The fix
In those recorded cases, the fix was to route the write through Elementor’s own editor save pipeline. The following snippet is the historical implementation example; use the current supported editor and exact widget/settings contract for a new edit. Open the real editor (/wp-admin/post.php?post=<id>&action=elementor), wait for the elementor/$e globals, walk elementor.documents.getCurrent().container to find the target widget’s Container, then run:
$e.run('document/elements/settings', { container: c, settings: { html: newHtml } });
await $e.run('document/save/update');
This worked immediately on nathanielstevens.com — same HTML string, only the save path changed. For the observed 3.32.3 and 3.34.2 cases, the supported editor save resolved the reported rendering problem. For another site or version, inspect its maintained builder data and current supported save route, preserve unrelated fields, then verify saved data and the ordinary public render. Do not infer a version-wide API rule from these two cases. The July 2026 test on Elementor 4.0.8 at camhazzard.com did not reproduce that failure. This comparison records those tested setups only; it does not certify all 3.x or 4.x versions or a future save API.
A second gotcha: don’t use DOMParser on an HTML fragment
new DOMParser().parseFromString(html,'text/html') on a body-only fragment can auto-hoist a leading <style> tag into an implicitly-created <head>. If you then serialize with doc.body.innerHTML, that entire stylesheet silently disappears — no error, no warning, just gone. We caught this before saving on dylan-haugen.com by diffing style-tag counts before and after.
Fix: parse fragments with document.createRange().createContextualFragment(html) with the correct context and verify its output; in this recorded repair it preserved the leading stylesheet and other elements (including <style> tags) in the intended fragment. Always verify a mutation by comparing tag-name counts (div, img, style, etc.) and normalized textContent before and after, before saving anything.
Implementation checklist for any new build
| Step | Do this |
|---|---|
| 1 | Confirm each card has a relevant real image. Reuse verified featured media or an inspected source-video frame when available; otherwise obtain an appropriate real photo. Do not invent proof or assume a plugin generated it. |
| 2 | Check the card’s computed overflow value; pick negative-margin bleed or wrap-in-body-div accordingly (default to wrap-in-body-div for anything new). |
| 3 | For a body-only fragment, use createContextualFragment with the correct context and verify the output. The recorded DOMParser failure came from serializing only the parsed body after a leading style was moved into the head. Check styles, element counts, links and text before saving. |
| 4 | For the recorded Elementor 3.32.3 and 3.34.2 fixes, the editor save used $e.run('document/elements/settings') + document/save/update from the live editor. For the current site, use its supported save route and verify the exact affected field and public result. |
| 5 | Use the site’s current supported cache controls. The reference builds used Elementor’s Clear Files & Data control and, where present, the page-cache plugin such as WP Rocket. After a supported cache operation, verify the ordinary canonical URL anonymously and inspect the rendered cards at desktop and mobile widths. A cache-busted diagnostic or logged-in preview alone does not prove what normal visitors see. |
Historical Rollout Recorded July 5, 2026
Meaningful real thumbnails remain the pattern for article cards on the personal-brand homepages we build or update. The table below preserves the original account published July 5, 2026, including its then-open login and rollout items. It is not a fresh check of current site, access or fleet status; use each owning record and ordinary-route receipt for a present-day claim.
| Site | Status | Note |
|---|---|---|
| camhazzard.com | ✓ Live, verified | Negative-margin bleed technique, Elementor 4.0.8. |
| nathanielstevens.com | ✓ Live, verified | Wrap-in-body-div, saved via $e.run after the raw-REST img-stripping bug was found and fixed. |
| dylan-haugen.com | In progress | Content/links refreshed and saved; thumbnails prepared but not yet rendering live — needs the same $e.run fix, blocked on a fresh WP-admin login. |
| georgeleith.com | N/A | Homepage has no blog-teaser section to fix; its /blog/ archive already shows thumbnails natively via the theme loop. |
| Remaining ~193-site fleet | Queued | Standard added to the provisioning checklist for all new builds; backfilling existing sites is blocked on the same Application Password fleet-provisioning gap tracked elsewhere. |
The Reference Sites and Original Build Story
Reference sites from the July 2026 build account: camhazzard.com and nathanielstevens.com. Original build story and per-site status: the meta article (a record of one task run) below.
Originally published .