Why I am not teaching Elementor V4 to my students yet

I am preparing an Elementor session for publishing students. Before writing the material, I wanted to know exactly what they would see when installing the plugin. The official documentation gave me one answer. The plugin's source code gave me another, more precise one, and that is the one that decided how I would teach it.

Elementor moved to version 4 in late March 2026. New number, new editor, new vocabulary: atomic elements, global classes, components. The official FAQ states: "Starting in April 2026, all new Elementor sites will run on version 4 by default."

My students install the plugin next Wednesday. If my material describes one interface and they see another, the session is wasted.

1. The documentation answers the wrong question

The official FAQ is clear on the principle: "On every new Elementor installation, atomic features are enabled by default and the new Atomic Elements appear at the top of the Elements panel."

But what counts as a "new installation"? A fresh WordPress install? Or a plugin installed for the first time on an existing site? My students' WordPress sites were set up two weeks earlier, already holding content and other plugins.

So I stopped reading the documentation. With Claude Code connected to the server, I installed the plugin on my demo site and dug into its code.

2. Three lines of PHP worth the whole FAQ

Elementor ships its new features through an experiments system. Each one has a name, a status and a default state. A WP-CLI command lists them on a real installation:

wp eval '
$m = \Elementor\Plugin::$instance->experiments;
foreach ($m->get_features() as $k => $f) {
  printf("%-34s %-8s defaut=%-8s statut=%s\n",
    $k,
    $m->is_feature_active($k) ? "ACTIF" : "inactif",
    $f["default"] ?? "?",
    $f["release_status"] ?? "?");
}
'

My demo site is a WordPress install set up for the course ten days earlier, with its own content and plugins, but it had never run Elementor. With version 4.3.2, the output contains these two lines:

e_atomic_elements                  ACTIF    defaut=active   statut=beta
e_opt_in_v4                        ACTIF    defaut=active   statut=alpha

Both version 4 features are active. Yet the statuses read beta and alpha, while Elementor has been promoting a stable release since March. An apparent contradiction. The file registering that experiment explains it:

Plugin::$instance->experiments->add_feature([
    'name'           => 'e_opt_in_v4',
    'title'          => 'Editor V4',
    'hidden'         => true,
    'default'        => Experiments_Manager::STATE_INACTIVE,
    'release_status' => Experiments_Manager::RELEASE_STATUS_ALPHA,
    'new_site'       => [
        'default_active'               => true,
        'minimum_installation_version' => '4.0.0',
    ],
]);

It all comes down to the three lines of the new_site block. The global default is inactive; that block overrides it for any site whose first Elementor installation is 4.0.0 or later. The hidden flag, meanwhile, removes it from the experimental features screen.

So the alpha and beta labels are internal code markers, not the product's commercial status.

3. What the code calls a new site

One question remained: how does Elementor date that first installation? The function that settles it is called install_compare:

private function install_compare( $version ) {
    $installs_history = Upgrade_Manager::get_installs_history();

    if ( empty( $installs_history ) ) {
        return version_compare( ELEMENTOR_VERSION, $version, '>=' );
    }

    $cleaned_version = preg_replace( '/-(beta|cloud|dev)\d*$/', '', key( $installs_history ) );

    return version_compare( $cleaned_version, $version, '>=' );
}

Elementor keeps a history of every version ever installed on the site, in the elementor_install_history option. The function reads the first entry of that history, and only that one. The age of the WordPress install does not count. Neither does its content.

A reading of the code remains a hypothesis until you test it against reality. I had the perfect counterexample at hand: a hosting account still running a site built by one of last year's students, with Elementor and Elementor Pro. I read the history of both sites:

# Demo site
elementor_install_history : {"4.3.2":1790355296}
  -> first version : 4.3.2 (25/09/2026)     e_opt_in_v4 : ACTIF

# Last year's site
elementor_install_history : {"3.32.3":1759232291,"3.32.4":1761045692,
                             "3.33.4":1765227506,"3.35.5":1771358779,
                             "4.2.4":1788420383}
  -> first version : 3.32.3 (30/09/2025)    e_opt_in_v4 : inactif

The second site has run 4.2.4 since early September. Same major version, opposite behaviour: its atomic elements are missing from the panel, because its first version was 3.32.3. The hypothesis holds.

4. Counting the building blocks: my first figure was wrong

First count: 9 atomic widgets against 140 classic ones. I nearly wrote that V4 was an almost empty shell.

Elementor stores its widgets in one registry and its structural elements (containers, tabs, loops) in another. I had only queried the first. The full count of registered building blocks, on the same installation:

The official roadmap confirms the measurement: atomic loop, grid and accordion shipped in July 2026. Two building blocks a portfolio needs are still missing on the atomic side: the carousel, scheduled for October, and the gallery, which is not on the roadmap.

Above all, V4 does not replace V3. Both coexist on the same page, as the FAQ states in so many words. Two architectures in one screen, all the way down to the code: a classic heading and an atomic heading share neither a PHP class nor a settings system.

5. The test my lesson plan hinged on

My next session covers displaying custom fields: a custom post type, ACF fields, and a page template that renders them automatically. Without dynamic content, that session cannot happen.

Dynamic content is Elementor Pro only. On last year's site, which has it, I counted the settings accepting a dynamic value, then the registered ACF tags:

heading      : 9 controle(s) acceptent le contenu dynamique
text-editor  : 7 controle(s) acceptent le contenu dynamique
image        : 10 controle(s) acceptent le contenu dynamique

8 balises ACF : acf-text, acf-image, acf-url, acf-gallery,
                acf-file, acf-number, acf-color, acf-date-time

With classic widgets and Elementor Pro, the path exists on a real installation: the tags are registered and the settings accept them.

On the atomic side, the answer is murkier. Elementor publishes a help page dedicated to dynamic content in V4: the feature exists. But report #35820, titled "Atomic elements lose styling when referencing ACF fields", describes my session's scenario exactly: the field value displays, the styling you set disappears. Opened on 11 May 2026, it has not moved since 20 May. Three minor versions have shipped since.

Actual status: undetermined. For a course, an undetermined status on the critical path is answer enough.

6. The argument that really settled it

It was not the ACF bug. It was a more troublesome family of reports: atomic styles that fail to apply, or fail to load, once the page is displayed.

As of 25 September 2026, I count seven open reports on that problem in Elementor's public repository. The oldest dates from April, the newest, #37385, from 22 September. Five are still waiting for their first triage; only one is labelled as fixed in 4.1, without ever having been closed. Their titles alone sketch the symptom: styles lost inside a template, lost inside a loop, global styles ignored, CSS files responding intermittently (#37299). In the editor, the page looks right. Once published, it may not.

The release pace clinched it. Three versions in three days, according to the changelog shipped inside the plugin: 4.3.0 on 22 September, 4.3.1 on the 23rd, 4.3.2 on the 24th. Version 4.3.1 threw an exception alongside Elementor Pro 3.29.2 (#37443); Elementor closed the report the same day, without a fix, asking users to update Pro. Across a semester, that is a risk surface I do not control.

7. Two official pages that contradict each other

The official FAQ states that the Grid and Loop elements "are already in development". The official roadmap lists them as shipped in July 2026. And my own count finds them installed.

Checked on the same day, the two pages contradict each other. It is not a scandal: a FAQ ages faster than a roadmap.

I teach my students that a plugin is judged on four criteria: active installations, last update date, declared compatibility, quality of reviews. This case adds a fifth, which applies to keeping up with any technology: official documentation is not gospel. It has a date, an author, and sometimes a page in the next room contradicting it.

8. What I am planning for the class

This year, I am teaching classic widgets. The rest is a working plan, not a rule yet:

• Disable nothing - both families coexist in the same editor, and every manual setting makes machines drift apart.
• Name what they see - the atomic section is the first thing students notice. Five minutes of explanation head off a barrage of questions.
• Pin one version for the whole class - from 4.0 to 4.3 in six months, machines that fall out of sync end up showing different interfaces.
• Write "version 4.x" in the material - any precise number will be stale by January.

And a note for next year. The atomic model rests on reusable classes rather than styling applied element by element. That is what we teach in CSS. Once the carousel lands and the styling reports are closed, V4 will probably make a better teaching tool than V3.

What I take away

• Source code answers the questions documentation rephrases. A function of about ten lines gave me the exact rule where the FAQ stayed approximate.
• A reading of the code is best tested against the opposite case. The site without V4 proved my reading better than the one that had it.
• A raw number misleads without its model. My "9 against 140" was wrong twice: V4 does not replace V3, and I had only queried one registry out of two.
• In teaching, the cost of an unstable tool is not the breakage itself. It is the learner who blames themselves for a defect that is not theirs.
• A contradiction between two official pages beats a good lecture on keeping up with technology. It is dated, verifiable, and it teaches doubt on my behalf.

I will not teach version 4 this year. Maybe next year, after running exactly the same tests again.