← All sessionsHomeSearch
LWP Elementor Pro Mastery·2 - How to control content globally with Dynamic Content·1:58:34

Section 2: Dynamic Content — Post Types, Fields, and the Whole Template System

Reno Instructor — builds the complete dynamic-content architecture across 13 lessons: custom post types and fields with ACF, then every Elementor template kind (header/footer, single post, loop, loop grid, archive, single page, saved) with their conditions and URL plumbing
▶local recording  ·  LMS lesson

Session map

THE DATA LAYERTHE TEMPLATE LAYERTHE PAYOFFEverything is a postblog, products, and custom post types d…The template system, mappedwhat has conditions, what doesn't, and…Current querythe one setting that makes archives act…The business caseclients edit content, never the design…
The data layerThe template layerThe payoff
click a node — its card pops up (drag it anywhere, × to close)
Concept

The map reads left to right — the data layer flow into the template layer, then into the payoff. Click any node to open that idea here; every timestamp jumps into the recording.

The short version

  1. The chapter's promise: 'make your website smarter and faster and easier to edit for your clients' — content saved once (posts, custom post types, custom fields) and rendered everywhere by templates, so clients add a testimonial or job without ever opening Elementor.
  2. The data layer: WordPress post types are all the same machine with different fields — blog posts, WooCommerce products, and your own custom post types (ACF is his pick: 'everything is in one package'), each extendable with custom fields (text, number, image, location) with validation and client-facing instructions.
  3. The template layer, mapped completely: header/footer (conditions: entire site), single post (per post type), loop items (no conditions — placed by the loop grid widget), archives (MUST use current query, and conditions must include categories), single page (per-page conditions for legal-page families), and saved templates for shared pricing tables/FAQs/sidebars.
  4. The URL plumbing nobody teaches: the blog archive attaches to an empty page via Settings→Reading; /blog/ permalink prefixes leak onto custom post types unless disabled per-CPT; the post type key must NEVER change after creation; custom permalinks and archive slugs do the renaming safely.
  5. Deliberately non-chronological: 'you first need to understand the big picture... don't expect that we're gonna build all of this together' — the build order is a later chapter; this one is the map.

The concepts

01

Everything is a post: blog, products, and custom post types differ only in fields

Install WooCommerce and you get 'products' — which are just posts wearing pricing fields.

The unifying idea of the chapter: WordPress has one content machine — lists of posts with fields. The blog is that machine with title/content/image/categories. WooCommerce products are the same machine with pricing, inventory and sale fields bolted on. And custom post types are the same machine with YOUR fields: testimonials (text, photo, name, role), team members, job listings (hours, salary, location). Categories and tags — jointly 'taxonomies' — ride along on any of them, and hierarchical taxonomies give real categories rather than tags.

Once seen this way, every feature that works for blogs (archives, loops, singles, excerpts) works for everything else — which is exactly how the rest of the section proceeds.

Worked example · from the session

The jobs walk-through: a 'jobs' post type created in ACF in under a minute, given a hierarchical 'job categories' taxonomy, an icon from the icon library, a menu position, and then fields — hours (text), salary (number with min/max validation), image, and a location text field that feeds Elementor's map widget.

Why it matters

This is the mental unlock that turns WordPress from 'a blog tool' into a general content database — the foundation of client-editable sites.

People get this wrong

Custom post types are an advanced developer feature.

ACF creates one in a form: plural name, singular name, save. The sophistication is in choosing WHAT deserves to be a list — not in the mechanics.

Everything is a post The post machine one primitive Blog post default fields Product + price fields Custom type + your fields Templates + current query archives just work Types differ only in fields; templates + the current-query setting render them all
One post machine: types differ only in fields; templates + current query render them all
Just leave the post type key for what it is. Never change it.
For your projects

["HUDDLE's member/organization lists are textbook CPT material if it ever moves WordPress-side; the pattern also maps to any headless CMS."]

Go deeper

In one line: All WordPress content types are posts with different field sets: built-in posts (blog), WooCommerce products (commerce fields), and ACF-created custom post types (your fields). Taxonomies (categories/tags) attach to any; hierarchical taxonomies behave as categories. Every template mechanism then applies uniformly.

'Webshop products are just other kinds of posts with different fields like a pricing field' (l1424758 08:07)

Custom post types exist for 'when you want an extra list' beyond blog and products (l1424758 10:07)

Categories + tags = taxonomies; set hierarchical=on to get category behavior (l1424761 06:04)

Custom fields extend any post type: 'they're not the normal fields which you already get — they're custom fields. That's it.' (l1424758 14:08)

Try it now

Name three lists on any site you run (team, FAQs, locations, projects…). Each is a custom post type wearing different fields — that's the whole design exercise.

▶ Watch this taught:

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

What's the actual difference between a blog post, a product, and a testimonial in WordPress?

Only the field set. All three are posts; archives, singles, loops and excerpts work identically on each.

02

The template system, mapped: what has conditions, what doesn't, and why loops are special

Publishing a loop opens no conditions dialog — and the moment you understand why, the whole theme builder makes sense.

The theme builder's kinds, each with its jurisdiction: header/footer templates claim site chrome (conditions: include entire site, with per-page excludes). Single post templates render the page behind every post of a type (conditions: that post type). Archive templates render auto-generated list pages including category pages (conditions: the archive AND its categories). Single page templates skin ordinary pages that share a design — legal-page families — with per-page conditions. Saved templates hold widget compositions (pricing tables, FAQs, sidebars) for reuse via the template widget.

Loops are the exception that teaches the rule: a loop item is a preview card design, and it has NO conditions because placement isn't its job — the loop grid widget places it anywhere (a static homepage section, an archive body, related-posts). 'These loops don't have a condition... you can drag in a loop anywhere.'

Worked example · from the session

The finished site tour: header v1/footer v1 on the entire site; blog single vs jobs single with different conditions; testimonial and jobs archives; a legal-pages single-page template covering privacy/terms/refund; sidebar and pricing-table saved templates reused across pages.

Why it matters

Condition errors are the number-one 'why isn't my template showing' failure — knowing each kind's condition semantics is the debugging map.

People get this wrong

Templates know where they belong.

YOU bind them — via conditions for most kinds, via widget placement for loops and saved templates. The preview selector binds nothing.

If there's a link inside of a link then Elementor doesn't like that and it will probably crash.
Elementor is not as easy as they make it look, especially when you wanna work in the most efficient way possible.
For your projects

['The has-conditions/no-conditions split parallels your build_site pages vs shared components — binding logic vs composition logic.']

Go deeper

In one line: Template kinds and their binding: header/footer (site-wide include/exclude), single post (per post type), archive (archive + categories/tags in conditions, current query inside), single page (explicit page list), saved templates (no conditions; placed via template widget), loop items (no conditions; placed via loop grid widget).

Preview ≠ conditions: the preview setting only chooses sample data; conditions do the binding (l1424763 02:00)

Loops have no conditions by design — placement belongs to the loop grid (l1424764 10:05)

Single page template: 'you can still use the pages but you control the design from one place' (l1424768 00:00)

Saved templates: for widget compositions where a CPT would be overkill — pricing tables, FAQ, sidebar (l1424769 00:00)

Naming convention throughout: 'Header version 1... sometimes you have different versions' (l1424759 02:02)

Try it now

Open your theme builder and audit every template's conditions against this map — especially archives missing their category line.

▶ Watch this taught:

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

Your archive template works, but category pages fall back to the theme default. What's missing?

The conditions include only the post archive — add the categories (and tags if used) of that post type as additional include lines.

03

Current query: the one setting that makes archives actually work

His demo archive showed the same posts on every category page — until one dropdown changed everything.

Inside an archive template's loop grid, the query source must be 'current query' — not the post type itself. Selecting the post type hard-codes the list, so /category/tips-and-tricks shows ALL posts, categories be damned. Current query means 'whatever list WordPress is generating for this URL' — the category page filters itself, the tag page filters itself, all through one template.

The companion trap is on the conditions side: even with current query, category pages fall back to the theme default unless the conditions explicitly include the categories. And a third: ACF ships new post types with the archive toggle OFF — no archive option appears anywhere until you enable it in the CPT's advanced URL settings.

Worked example · from the session

Demonstrated as a failure first: query set to 'posts' → the knowledge-and-insights category shows unfiltered posts; flipped to current query → correct filtering; then the category condition added → the fallback-to-Hello-Elementor bug disappears.

Why it matters

This is the section's highest-leverage three minutes — the difference between an archive system and a broken blog.

People get this wrong

An archive template is just a page with a loop grid.

It's a URL family renderer — the current-query setting and category conditions are what make one template serve dozens of auto-generated pages.

We can just create a page without creating a page, if you know what I mean.
For your projects

['The current-query idea = parameterized rendering; your toc pages do the same thing over courses.']

Go deeper

In one line: Archive templates require query source = current query (URL-driven filtering) rather than a fixed post type; their conditions must include the post type's categories/tags alongside the archive; and ACF custom post types need their archive setting enabled before any of it exists. WooCommerce product archives live under a separate theme-builder entry and handle categories automatically.

'If you leave current query here... no matter what kind of category you click on, it will display that' (l1424766 02:00)

Fixed-query archives ignore categories — shown failing live (l1424766 02:00)

Conditions need the categories line 'because for some reason, if you just put it on post archive... it doesn't work' (l1424766 04:01)

ACF archive toggle is off by default — 'make sure to check it inside of your custom post type plugin' (l1424766 04:01)

WooCommerce: separate products-archive button; categories work without the extra condition — 'I also don't know why' — but adding both is 'always safer' (l1424766 06:03)

Try it now

Open any archive template you own: check query = current query, conditions include categories, and (for CPTs) the ACF archive toggle is on. Three checks, three classic failures.

▶ Watch this taught:

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

Why does a loop grid on a normal PAGE select its post type directly, while the same widget in an ARCHIVE must not?

A page shows a fixed list — you choose it. An archive renders many URLs (all categories/tags) from one template — current query lets the URL choose.

04

The business case: clients edit content, never the design — and the site gets faster

'The last thing you want is your client constantly calling you like, hey, can you change this person?'

The architecture's payoff is operational: give the client a WordPress login, and team changes, new testimonials, and job postings are their work, not yours — add a post, fill the fields (with your instructions and validation guarding them), publish. The design never gets touched because the design lives in templates. Backend polish is part of the method: field instructions, prepend/append labels ('$' before, 'per month' after), field widths (50/25/20%), reordered field groups above the content box, and even deleting the featured-image box — 'make it as easy as possible for your clients.'

The second payoff is speed, named in the reflection: 'the less content is saved, the less it has to load' — single-source content plus templates beats page-by-page duplication on performance, not just maintainability.

Worked example · from the session

The jobs demo end-to-end: salary edited in one field → single page AND loop preview both update; a new 'manager' post → its page auto-exists with the shared design; validation blocks a six-figure typo at publish.

Why it matters

This is what the client is actually buying — a site they can run — and what you're selling when you architect with CPTs instead of page builders' defaults.

People get this wrong

Client-proofing means locking clients out.

It means routing them in — to fields designed so the right edit is the easy edit, while templates keep design untouchable.

Make your website smarter and faster and easier to edit for your clients — that's what you can do with dynamic content.
The less content is saved, the less it has to load.
For your projects

['Same pattern as your certificates.yaml → certificates.html: data entry by humans, rendering by machine.']

Go deeper

In one line: Dynamic architecture converts content changes into form-filling: clients CRUD posts through curated fields (instructions, validation, backend labels, widths) while templates own all design; performance improves because content is stored once. The instructor's backend-polish checklist is part of the deliverable.

Clients 'easily add a new testimonial... without opening the Elementor editor, without messing up your design' (l1424758 12:07)

Backend UX toolkit: instructions, required + min/max validation, prepend/append, width percentages, group placement, editor/featured-image removal (l1424762 throughout)

Placeholder text rejected: 'looks like there's already some data in here — that's not really good' (l1424762 04:02)

Speed rationale: 'the things we have covered... makes your website so much faster because the less content is saved, the less it has to load' (l1424770 00:00)

Chapter framing: smarter, faster, easier to edit — the three benefits in one sentence (l1424757 00:02)

Try it now

Pick one client-editable list on a site you manage and time the edit path: if it involves opening the page editor, the architecture — not the client — is the problem.

▶ Watch this taught:

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

Name three backend-polish moves that make a custom field client-proof.

Instructions on the field, validation (required, min/max), and prepend/append labels showing the expected format — plus width and ordering for scannability.

Every concept, three clicks deep

The same concepts as a quick reference: the closed row is the glance, open is the study card, and every timestamp jumps into the recording.

01Everything is a post: blog, products, and custom post types differ only in fieldsAll WordPress content types are posts with different field sets: built-in posts (blog), WooCommerce product…›

All WordPress content types are posts with different field sets: built-in posts (blog), WooCommerce products (commerce fields), and ACF-created custom post types (your fields). Taxonomies (categories/tags) attach to any; hierarchical taxonomies behave as categories. Every template mechanism then applies uniformly.

'Webshop products are just other kinds of posts with different fields like a pricing field' (l1424758 08:07)

Custom post types exist for 'when you want an extra list' beyond blog and products (l1424758 10:07)

Categories + tags = taxonomies; set hierarchical=on to get category behavior (l1424761 06:04)

Custom fields extend any post type: 'they're not the normal fields which you already get — they're custom fields. That's it.' (l1424758 14:08)

02The template system, mapped: what has conditions, what doesn't, and why loops are specialTemplate kinds and their binding: header/footer (site-wide include/exclude), single post (per post type), a…›

Template kinds and their binding: header/footer (site-wide include/exclude), single post (per post type), archive (archive + categories/tags in conditions, current query inside), single page (explicit page list), saved templates (no conditions; placed via template widget), loop items (no conditions; placed via loop grid widget).

Preview ≠ conditions: the preview setting only chooses sample data; conditions do the binding (l1424763 02:00)

Loops have no conditions by design — placement belongs to the loop grid (l1424764 10:05)

Single page template: 'you can still use the pages but you control the design from one place' (l1424768 00:00)

Saved templates: for widget compositions where a CPT would be overkill — pricing tables, FAQ, sidebar (l1424769 00:00)

Naming convention throughout: 'Header version 1... sometimes you have different versions' (l1424759 02:02)

03Current query: the one setting that makes archives actually workArchive templates require query source = current query (URL-driven filtering) rather than a fixed post type;›

Archive templates require query source = current query (URL-driven filtering) rather than a fixed post type; their conditions must include the post type's categories/tags alongside the archive; and ACF custom post types need their archive setting enabled before any of it exists. WooCommerce product archives live under a separate theme-builder entry and handle categories automatically.

'If you leave current query here... no matter what kind of category you click on, it will display that' (l1424766 02:00)

Fixed-query archives ignore categories — shown failing live (l1424766 02:00)

Conditions need the categories line 'because for some reason, if you just put it on post archive... it doesn't work' (l1424766 04:01)

ACF archive toggle is off by default — 'make sure to check it inside of your custom post type plugin' (l1424766 04:01)

WooCommerce: separate products-archive button; categories work without the extra condition — 'I also don't know why' — but adding both is 'always safer' (l1424766 06:03)

04The business case: clients edit content, never the design — and the site gets fasterDynamic architecture converts content changes into form-filling: clients CRUD posts through curated fields…›

Dynamic architecture converts content changes into form-filling: clients CRUD posts through curated fields (instructions, validation, backend labels, widths) while templates own all design; performance improves because content is stored once. The instructor's backend-polish checklist is part of the deliverable.

Clients 'easily add a new testimonial... without opening the Elementor editor, without messing up your design' (l1424758 12:07)

Backend UX toolkit: instructions, required + min/max validation, prepend/append, width percentages, group placement, editor/featured-image removal (l1424762 throughout)

Placeholder text rejected: 'looks like there's already some data in here — that's not really good' (l1424762 04:02)

Speed rationale: 'the things we have covered... makes your website so much faster because the less content is saved, the less it has to load' (l1424770 00:00)

Chapter framing: smarter, faster, easier to edit — the three benefits in one sentence (l1424757 00:02)

Tools referenced

ToolCoverageMomentContext
ElementordemonstratedTheme builder end-to-end: header/footer, single post, loop, loop grid, archive, single page, saved templates, dynamic tags, conditions
ACFdemonstratedPost types, taxonomies, field groups, validation, presentation, URL/permalink controls — the chapter's second protagonist
WordPressdemonstratedClassic vs Gutenberg editors, menus, reading/permalink settings, screen options
WooCommercedemonstratedProducts-as-posts; separate archive entry; shop/cart/checkout page wiring
Classic EditordemonstratedThe chapter's editing-surface preference
Hello ElementordemonstratedThe default theme doctrine
AstrademonstratedUsed to demonstrate theme-part interference before Hello
Gutenbergmentioned'Trying to compete with page builders'; not covered
CPT UImentionedFormerly promoted; superseded by ACF's post-types feature
JetEngine (CrocoBlock)mentionedMore powerful, paid; principles identical
Google MapsmentionedAddress source for the map-widget location pattern

Action items

Resources mentioned

Resources
  • docACF — Advanced Custom Fields plugin
  • docWordPress dashicons library (icon picker link inside ACF visibility settings)
  • doc'Generate lorem ipsum' Chrome extension
  • docHis real-estate site example (properties CPT with gallery/location fields)

Extraction notes

This page was built from an auto-generated transcript, which garbles product and people's names. Those were corrected silently in everything above and logged here for transparency. The warnings flag claims that were true on the recording day but change fast.

Transcript corrections applied

The transcript saysThe trainer actually means
Rina from the futureReno from the future (trainer's retro-update segments; name now VERIFIED aloud)
hic et ipsum / lorem 2 ipsumlorem ipsum (filler text)
blocking platform / blocking was kind of limitedblogging platform / blogging
e sending and descendingascending and descending (sort order)
jelcy whitmore / Chelsea Whitmoredemo testimonial name (as heard)
sell a little bit (buttons)style a little bit
a a c fACF
LoopGrid / loop grid widgetLoop Grid widget
screen options... check landing pagesWordPress Screen Options checkboxes
hierarchical - sorry, there's a hard word for me to pronouncehierarchical (taxonomy setting; his own aside)

True on recording day — verify before relying