Elementor 4.3 beta adds taxonomy filtering, repeating alternate templates, static-position items, and custom empty states to Atomic Loops. Each feature is understandable alone. Combined rules can duplicate a post, shift the static item, break pagination, render the wrong alternate template, hide the empty state, or produce a layout that works only at the content count used during design.
Use this for news grids, product catalogs, staff directories, portfolios, case studies, event listings, real estate, knowledge bases, and any Elementor Pro page where dynamic content count, taxonomy, or pagination changes frequently.
Quick answer
On staging with Elementor 4.3 beta and Atomic Editor enabled, build a controlled set of posts across several taxonomies and statuses. Create one base loop template, alternates at different frequencies, a static item, and a designed empty state. Test zero, one, two, exact-frequency, one-over-frequency, several pages, no-result filter, mixed taxonomy, excluded post, sticky post, private post, and newly published post. Compare query IDs, order, duplicates, alternate positions, static position, pagination, keyboard focus, mobile layout, and cached output.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Zero results | Unmatched taxonomy | Custom empty state |
| Exact frequency | Six posts, every third | Alternates at 3 and 6 |
| Static item | Pinned at position 2 | No duplicate post |
| Pagination | Second page | Stable order and focus |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence | Verification |
|---|
| Freeze content IDs | Record Elementor, Elementor Pro, WordPress, PHP, Atomic Editor, experiment, theme, cache, query, taxonomy, order, pagination, alternate frequency, and static position settings. | Zero-result filters show the custom empty state and remove it immediately when a match exists. |
| Write expected positions | Create a fixed content fixture with known IDs, dates, terms, featured images, missing images, long titles, short titles, draft, private, sticky, excluded, and scheduled records. | Alternates, static items, exclusions, and pagination never duplicate or silently omit an eligible post. |
| Test boundary counts | Test zero through frequency plus one results, several pages, query-string filters, nested taxonomies, multiple alternates, repeated static positions, empty state, editor preview, and public page. | Visual order matches reading and keyboard order across desktop, tablet, and mobile. |
| Audit DOM and accessibility | Inspect DOM order, duplicate post IDs, heading hierarchy, landmark structure, link names, keyboard focus after filtering or pagination, lazy images, layout shift, and reduced-motion behavior. | Editor preview, logged-out public HTML, warm cache, and purged cache produce the same current query result. |
What to check first
- Record Elementor, Elementor Pro, WordPress, PHP, Atomic Editor, experiment, theme, cache, query, taxonomy, order, pagination, alternate frequency, and static position settings.
- Create a fixed content fixture with known IDs, dates, terms, featured images, missing images, long titles, short titles, draft, private, sticky, excluded, and scheduled records.
- Test zero through frequency plus one results, several pages, query-string filters, nested taxonomies, multiple alternates, repeated static positions, empty state, editor preview, and public page.
- Inspect DOM order, duplicate post IDs, heading hierarchy, landmark structure, link names, keyboard focus after filtering or pagination, lazy images, layout shift, and reduced-motion behavior.
- Repeat after publishing, unpublishing, retagging, deleting, restoring, cache warmup, cache purge, logged-in preview, logged-out visit, mobile, tablet, and RTL locale.
Field notes
- Write the pass condition before changing anything. A repeatable synthetic fixture makes the before and after comparison far more useful.
- Keep exact versions and UTC timestamps because scheduled jobs, caches, OAuth refreshes, retries, and background processing can change the evidence.
- Check the public experience and the stored server-side result. Admin previews and isolated API calls do not prove the whole workflow.
- Repeat the test after the relevant cache, queue, scheduled action, webhook, and observation window has finished.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
loop_fixture:
post_ids: [201, 202, 203, 204, 205, 206, 207]
taxonomy: topic:test
alternate_every: 3
static_position: 2
posts_per_page: 6
expected_page_1: [201, static, 202, 203, 204, 205]
Why this usually happens
- Alternate frequency is calculated before a static item is inserted, shifting later positions.
- Pagination and taxonomy filters use different query states between editor preview and public page.
- A cached empty state survives after the first matching post is published.
- The visual grid order differs from DOM order, confusing keyboard and screen reader users.
Decision rule
Approve the loop only when every content count and filter returns the written unique post order, alternate and static positions stay deterministic, empty states are accurate, and navigation remains accessible.
Production verification checklist
- Zero-result filters show the custom empty state and remove it immediately when a match exists.
- Alternates, static items, exclusions, and pagination never duplicate or silently omit an eligible post.
- Visual order matches reading and keyboard order across desktop, tablet, and mobile.
- Editor preview, logged-out public HTML, warm cache, and purged cache produce the same current query result.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Freeze content IDs
- Write expected positions
- Test boundary counts
- Audit DOM and accessibility
- Repeat after content changes
Mistakes to avoid
- Changing production before recording plugin versions, WordPress version, PHP version, UTC time, the exact fixture, and a tested rollback point.
- Accepting one successful admin screen while the public form, stored record, API response, accessibility tree, cache, email, or downstream system remains unchecked.
- Testing only as an administrator instead of the role, browser, device, locale, network state, and failure path that a real customer reaches.
- Leaving test accounts, broad credentials, debug logs, temporary compatibility filters, or synthetic customer data active after verification.
Questions teams ask during testing
Should I test this on production?
Use production for read-only evidence first. Reproduce the change on staging with a current data shape, theme, extensions, caching stack, and browser mix. If a production canary is necessary, make it reversible, identifiable, monitored, and unable to charge a customer or expose personal data.
How do I know the result is not a cache artifact?
Record the origin response, purge only the affected paths, and repeat the test in a private session and a normal session. Compare stored data and server logs with the visible page. A cache hit is useful evidence only when you know which version it contains.
What belongs in the evidence packet?
Keep UTC time, exact versions, fixture ID, role, browser, expected result, actual result, relevant response or log lines, change made, rollback point, owner, and final verification. Redact passwords, tokens, personal data, and private URLs.
When can I close the test?
Close it when the primary path and important failure branches pass, records reconcile across systems, accessibility and mobile checks are complete, temporary changes are removed, and monitoring covers the next update or business cycle.
What to tell the client or owner
Give the owner a short packet with the affected workflow, exact versions, UTC test time, fixture ID, expected result, actual result, key evidence, change made, rollback point, unresolved risk, owner, and next review date. Remove credentials and personal data before sharing it.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, have HandL WP test an Elementor 4.3 layout.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references