Elementor 4.2 is the release where the Atomic Editor stops feeling like a preview and starts covering the layouts people actually build. Two things arrived that had been high on the roadmap since version 4.0 shipped in March: native CSS Grid, and Loops.
If you have been holding off on the atomic workflow because it could not do the layouts you build every week, this is the release that changes the calculation. If you are running an established version 3 site, nothing about this forces your hand. Both remain true at once.
Native CSS Grid, properly
Grid arrives as a dedicated element rather than a workaround stacked on top of flex containers. It includes track controls, child spanning, and dense auto placement, which together cover the layouts that were awkward before: card grids where one card spans two columns, galleries with mixed tile sizes, feature sections where the visual rhythm is deliberately uneven.
The part that matters for agency work is that Classes and Variables apply natively to Grid elements. You are not dropping into custom CSS to hold a grid together, and you are not maintaining grid definitions in two places. That has been the recurring cost of doing grid layouts in a page builder, and it is largely gone here.
A practical note: use grid where the layout is genuinely two dimensional. Most page sections are one dimensional and a flex container is still the simpler, lighter answer. Reaching for grid on everything is how you end up with a page that is harder to make responsive, not easier.
Atomic Loops
Loops bring query driven repeatable content into the atomic system, with customisable pagination. This is what powers a blog listing, a portfolio grid, a product feed, a testimonial carousel driven by real posts rather than duplicated boxes.
The detail worth knowing: Atomic Loops support existing version 3 Loop Item templates. If a site already has loop templates built, they are not dead weight. That single decision removes most of the migration friction that would otherwise have kept dynamic sites on version 3 indefinitely.
Forms and accessibility
Atomic Forms picked up a secondary email action, so a submission can notify two different addresses without a third party plugin, plus autocomplete support and accessibility improvements. Autocomplete matters more than it sounds on mobile. A contact form that lets a phone fill in name, email and phone number from stored details converts noticeably better than one that fights the browser.
Performance fixes you will feel in the editor
This release resolves performance regressions around deeply nested containers, and specifically around Grid containers. If the editor had started feeling sluggish on complex pages, update before assuming your hosting is the problem. Editor performance and front end performance are different problems, and this fix is the former. For the latter, our notes on Elementor sites loading slowly still apply.
Where this leaves an existing site
Elementor has been consistent on this point and it is worth repeating, because clients get nervous when they read release notes. Atomic features are on by default for new installations only. Updating the plugin on an existing site does not change how that site is built or how it renders. Version 3 widgets and version 4 atomic elements can sit on the same page. You opt in, per site, when you choose to.
Our working rule:
- New builds starting now: start atomic. Set up Variables and Classes as a design system first, then build. It is faster once you are in it, and new installs come that way anyway.
- Existing sites in maintenance: leave them. There is no benefit to migrating a finished site that is performing well, and there is a real cost in QA time.
- Existing sites due a refresh: migrate as part of the refresh, not as a separate project. You are already testing every page.
- Mid build right now: finish in the workflow you started in. Switching architectures halfway through a build is how deadlines slip.
If you are weighing the underlying question of whether to be on the atomic architecture at all, we covered that separately in should you switch to the Atomic Editor. And if the real question is page builder versus blocks, Elementor versus Gutenberg is the more useful comparison.
The short version
4.2 fills in the two biggest gaps in the atomic system. Grid handles the layouts that previously needed custom CSS, and Loops handle dynamic content while respecting the loop templates you already built. Neither forces a change on an existing site. Both make starting a new one in version 4 the easier decision than it was three months ago.
Frequently asked questions
What is new in Elementor 4.2?
The two headline additions are native CSS Grid and Atomic Loops. Grid arrives as a dedicated element with track controls, child spanning and dense auto placement. Loops bring query driven repeatable content with customisable pagination. Both work natively with Classes, Variables and Components. The release also improves Atomic Forms and fixes performance regressions in deeply nested containers.
Do I have to switch my existing site to the Atomic Editor?
No. Atomic features are enabled by default on new Elementor installations only. Existing sites keep working exactly as they are, and you can activate atomic features manually when you are ready. Version 3 widgets and version 4 atomic elements can sit on the same page.
Can I use my existing Loop Item templates with Atomic Loops?
Yes. Atomic Loops support existing version 3 Loop Item templates, so the loop templates you already built do not need to be rebuilt before you can use the new loop element.
Is CSS Grid in Elementor better than using containers?
For genuinely two dimensional layouts, yes. Card grids, galleries and feature sections where you need control over both rows and columns are exactly what grid is for. Flex containers remain the right tool for one dimensional layouts, which is most of a typical page. Use grid where the layout is a grid, not everywhere.
Should new client sites start in version 4?
For most new builds started now, yes. The atomic workflow with Classes and Variables is faster once a design system is set up, and new installations start with it enabled anyway. For an existing site mid project, finish in the workflow you started in and migrate when you are refactoring regardless.