Atomic Editor styles are saved but not generated on the frontend

[omidpand]

Description

I am experiencing a frontend rendering issue with Elementor Editor V4 / Atomic Elements.

The layout appears correctly inside the Elementor editor, but the Atomic Flexbox styles are not applied on the frontend. The HTML elements and their Atomic class names are present, but Elementor does not generate the corresponding CSS rules.

Environment:

WordPress: 7.0.2
Elementor: 4.2.0
Elementor Pro: 4.2.0
PHP: 8.2.32
Theme: Xtra 5.9
Codevz Plus: 5.9
RTL website, Persian language

Example layout:

Parent Flexbox: row direction, 30px gap
Main column: 68% width, column direction
Sidebar column: 32% width, column direction, padding, border and background

The styles are correctly stored in the _elementor_data metadata. For example, the saved Atomic style data includes:

flex-direction: row
width: 68%
width: 32%
display: flex
padding, border, background and gap settings

The frontend HTML also contains the correct generated class names, such as:

e-019e025
e-ebe95f4-90db01f
e-6e63914-eb175c8

However, the generated post-1741.css file does not contain any CSS rules for these classes. The file is only about 865 bytes.

I have already tried:

Regenerating Elementor CSS using WP-CLI
Clearing the WordPress cache
Hard-refreshing and testing in an incognito browser
Changing the CSS print method from External File to Internal Embedding
Regenerating the CSS again after changing the print method

The issue remains in both CSS modes. The editor preview is correct, but the public page is displayed without the saved Atomic layout styles.

It appears that Atomic style data is being saved correctly but is not being compiled or printed on the frontend.

Please investigate whether this is an Elementor V4 Atomic CSS generation issue or a compatibility issue with third-party themes and widgets.

Agreement

• I confirm I have read and followed the Editor V4 Discussion Form guidelines, and agree this discussion may be closed without warning.

[krly-bit]

I´m having the same issue

[InfinityNT]

I had the same issue and tried the same steps you did. In the end, the fix was disabling CSS Minify (an option available in plugins like Perfmatters, LiteSpeed, etc.). It seems that when this is enabled, the styles generated by the Atomic design system aren't being delivered to the end user.

[JulioCortazar2]

I'm experiencing the same issue, with some additional network-level findings that might help pinpoint the cause.

Environment:

WordPress: 7.1
Elementor: 4.2.4
Site: staging environment (test-oficial subdomain)

Symptom:
Same as reported — Flexbox Container flex-direction renders correctly inside the Elementor editor at all times, but on the live frontend the container falls back to the default row direction instead of the saved column value. This is consistent across multiple browsers, incognito mode, and different devices, so it's not a browser/CDN cache issue. I also tried Elementor's manual "Regenerate CSS & Data" and it didn't resolve it.

What I found in the browser Network tab while editing/publishing:

On save, a GET request to /wp-json/elementor/v1/global-classes/usage returned a 403 Forbidden. (I initially suspected a REST permissions issue on my end related to a role-management plugin, but the 403 persisted even when logged in as a full administrator, ruling that out.)
On a subsequent save attempt (with Network "Preserve log" enabled and filtered to Elementor-related requests), I only saw two relevant XHR/fetch calls — both returning 204 No Content:
global-classes?context=front... — triggered via dispatchXhrRequest @ http-client.min.js?ver=4.2.4
stylesheet — triggered via syncDesignSystem @ design-system-sync.min.js?ver=4.2.4
The payload for the global-classes call was essentially empty: {"items":{},"order":[],"changes":{"added":[],"deleted":[],"modified":[],"order":false}}

So in my case there doesn't appear to be any request that actually persists the direction change to the atomic style — the client-side state shows the change, but nothing meaningful is sent to save it, or what's sent is empty. This lines up with what's described here: the layout data may exist correctly in the editor's local state, but the generated frontend CSS never reflects it — in my case it looks like the save/sync step itself (http-client.min.js → design-system-sync.min.js) isn't transmitting the changed value.