Our Elementor containers migration rebuilt noursky.com page by page: each page is first built as standalone HTML on one design system, passes an automated verification gate, and is then converted into an Elementor Pro template made only of flexbox Containers by a script that reads the built page’s DOM. Zero sections, zero columns, and no manual copying between page and template.
This is a first-hand case study from our own site, written for marketing leads and developers in Saudi Arabia, the UAE and beyond who run WordPress and Elementor and are deciding whether to move off sections and columns. It is the same method NourSky uses in web design and UI/UX projects. We describe the pipeline, the checks, and every Elementor bug that cost us time, with the fix.
Why migrate from sections and columns to containers at all?
Elementor introduced Flexbox Containers in version 3.6 (April 2022). Its announcement explains the problem with the old structure: to put four logos in a row you had to either set each widget to inline width or build a section with multiple columns, which Elementor itself says “harms performance”. Containers produce “a much slimmer markup”, and one container can switch from column to row “in a single click”.
Markup weight is not a cosmetic concern. Google’s Lighthouse flags a page when the body has more than about 800 DOM nodes and reports an error above about 1,400, because a large DOM slows loading, forces the browser to keep recomputing layout during interaction, and consumes memory. Every section-plus-column wrapper adds nodes that do nothing for the visitor.
So the decision was not whether to migrate, but how to migrate without the page and the editable template drifting apart.
How did we structure the migration?
We treated each page as a small software release with a fixed order:
- Diagnose the old page by measurement, not taste: what breaks, where it overflows, which text fails contrast.
- Build the page as standalone HTML on one design system file. Every color, font size and spacing value is a token from that file; the page carries a placeholder that is replaced by the full design system at build time, so no page holds its own copy of a color.
- Run the verification gate (next section). Nothing moves forward until it passes.
- Generate the Elementor template with a script that parses the finished HTML with a DOM parser and emits container JSON. No text is retyped by hand, so the page and the template cannot drift structurally.
- Write a report covering the diagnosis, decisions, gate results, the fixes caught, and any manual follow-ups for the site owner.
Headers and footers are left out of page builds on purpose, because they live as separate Theme Builder templates.
What does the verification gate check?
Each page is rendered in Chromium through Playwright and checked by Python scripts. The gate fails if any of these fail:
| Check | What passes |
|---|---|
| Layout at two viewports | At 1440×1000 and 390×844, scrollWidth equals innerWidth: zero horizontal overflow |
| Runtime errors | Zero JavaScript errors |
| Design system present | A design token actually resolves, proving the design system was injected |
| Reveal animations | Stepped scrolling (380px every 220ms) until every IntersectionObserver fires: zero elements stuck at opacity 0 |
| Accessibility | Programmatic WCAG 2.1 AA contrast audit; for gradients, the first stop is treated as the background |
| Template structure | Zero sections or columns, zero duplicate IDs, zero forbidden controls, and every row-direction container declares a mobile direction |
| Content parity | Diff between page and template: zero missing text; anything without a native widget equivalent is listed by name in an exemptions file |
| Behaviour | Where the page has behaviour, the full form path, and calculators at four input combinations |
Contrast gets its own automated check because it is the web’s most common failure. WCAG 2.1 success criterion 1.4.3 requires “a contrast ratio of at least 4.5:1” for normal text and 3:1 for large text. The WebAIM Million 2026 report found low-contrast text on 83.9% of the top one million home pages, averaging 34 instances per page.
Which Elementor bugs did we hit, and how did we fix them?
These are documented from the rebuild. Each one looked like a design problem and was actually a platform behaviour.
| Symptom | Cause | Fix |
|---|---|---|
| Columns collapse to nothing | width: 0% in the JSON is applied literally, not read as “fit content” |
Remove the width key; use flex-grow and flex-shrink |
| Last column drops to a new line | Percentages ignore gaps: columns summing 90% plus three 40px gaps exceed a 1112px container | Calculate widths with the gaps included |
| Form scripts misread choices | The Elementor form submits the visible option text, not a short code | An alias map shared by the HTML page and the template |
| Pricing comparison has no home | There is no table widget in Elementor core or Pro | Rebuild tabular content from containers, or list it in the exemptions file |
| FAQ widget at risk | The legacy Accordion widget is being retired on new sites | Native <details> and <summary>: no JavaScript, and screen readers treat it correctly |
| Validation messages are vague | The form widget has one generic “required” message, not one per field | Accept it, or state requirements in field labels and help text |
MDN describes <details> as a “disclosure widget in which information is visible only when the widget is toggled into an open state”, with the <summary> text used as its label. That is exactly an FAQ, without a single line of script.
What did we learn about motion and performance?
- IntersectionObserver can miss elements on fast scroll. When a visitor scrolls quickly, entries are merged and some elements never receive their reveal, staying at opacity 0. We added a debounced sweep as a safety net, and the gate’s stepped scroll proves it works.
- Budget the decoration. At most one grain layer and two light orbs per screen.
- Every animation respects
prefers-reduced-motion.
Why build RTL-ready if the site is English-only for now?
The Arabic version is deferred, so pages ship in English with RTL corrections already in the CSS layer. That surfaced a family of bugs worth knowing even before translating: physical inset does not mirror (use inset-inline and inset-block); centring with translate: -50% moves the wrong way in RTL (use inset-inline: 0; margin-inline: auto); and <svg> ignores dir, so any diagram with flow or arrows must be redrawn with mirrored coordinates. We cover all of them in Arabic RTL Web Design: 10 Bugs We Fixed and How.
Was there a security lesson?
One. The 404 page shows the path the visitor tried to open. That path is controlled by whoever writes the URL, so it is printed with textContent, never innerHTML. Writing it as markup would be a reflected XSS hole on the one page nobody thinks to review.
What we’ve seen in our projects
On noursky.com, most of the time the gate saved was not on dramatic failures but on quiet ones: a column that wrapped only at one container width because gaps were left out of the percentages, a section that stayed invisible only when scrolled quickly, a label that passed visually but failed the contrast ratio. None of these show up in a quick visual review on a designer’s screen. The content diff was the other lesson: once templates are generated from the page’s DOM, the only way text goes missing is a widget Elementor does not have, and the exemptions file forces every such case to be named.
How can you plan your own Elementor containers migration?
- Audit first: list pages still on sections and columns, and note which contain tables, legacy accordions or forms.
- Freeze a design system: tokens for color, type and spacing before rebuilding any page.
- Rebuild one representative page end to end, including the template, before scheduling the rest.
- Automate checks: two viewports, zero overflow, contrast, and reveal animations under fast scroll.
- Generate, do not retype: keep one source of truth for text.
- Migrate page by page, redirecting nothing until the new page passes.
Planning a move to Elementor containers?
NourSky rebuilds sites page by page for businesses in Saudi Arabia, the UAE and beyond, with the same verification gate we used on our own site.
FAQ
Do I have to migrate old Elementor sections to containers?
Existing sections keep working, but containers produce slimmer markup and simpler responsive control. Migrating page by page, with testing, avoids breaking live pages.
Why does my last Elementor container column wrap to a new line?
Usually because column percentages do not include the gaps. Four columns summing 90% plus three 40px gaps can exceed the container width. Include gaps in the calculation or use flex-grow.
Is there a table widget in Elementor?
No, not in Elementor core or Pro. Tables must be rebuilt from containers or placed in an HTML widget.
