Hi, thanks for reporting this.
To help narrow down the conflict, could you share a few details?
1. Which version of ECS is currently installed when the issue appears?
2. Which ECS modules do you have active (ECS > Modules in wp-admin)?
3. What exactly breaks — are the elements always visible, always hidden, or something else?
4. Any JavaScript errors in the browser console (F12 > Console) when the page loads?
In the meantime, you can try disabling ECS modules one by one to isolate which one causes the conflict. The most likely candidates would be Container Layout or Container Responsive, since those hook into the Elementor render pipeline.
The issue isn’t present in versions 3.17 and 3.19. When I upgrade to the latest version 4.3.1 I have issues. The module that appears to cause the issue is Container Content Layout. When I activate it disables the conditional display functionality site-wide. Any containers or Elementor elements set to “hidden” via the Essential Addons Conditional Display feature are visible. So they’re always visible.
Evaluation from Claude fwiw:
Ele Custom Skin’s Container Layout module is adding the e-ecs-flex class and intercepting the PHP render path for every Elementor flex container site-wide, including containers that have no skin, no Container Content Layout, and no slider configured in the editor. The side effect is that third-party plugins which hook into Elementor’s standard render filters — most notably Essential Addons Pro Display Conditions — are bypassed for the affected containers and their children. Elements that should be conditionally hidden are emitted into the page anyway.
Expected behavior
Ele Custom Skin should only decorate / re-render containers where a skin or Container Layout option has been explicitly configured by the user. Containers without any ECS configuration should pass through Elementor’s normal render path untouched, allowing other plugins’ elementor/frontend/container/before_render, elementor/frontend/widget/before_render, and elementor/widget/render_content filters to fire normally.
Actual behavior
Every Elementor container on the site receives the e-ecs-flex class in the PHP-rendered HTML, regardless of editor configuration. When the container is processed through ECS’s render path, the standard Elementor render filters do not fire for that container or its children. Essential Addons Pro Display Conditions, which suppresses widget output via those filters, is therefore never consulted, and conditionally-hidden elements appear in the DOM.
Likely cause
The Container Layout module appears to register a global container render override (or filter that always returns truthy for the “should ECS process this container?” check), rather than gating that override on whether any ECS-specific setting is actually present in the container’s saved data. The override then routes child rendering through a custom code path that does not re-invoke Elementor’s standard render filters.
Suggested fix direction
- Gate ECS’s container render override on the presence of at least one ECS-specific setting in the container’s data (e.g., a configured skin, Container Content Layout, slider, or color scheme). Containers with no ECS configuration should not be touched at all.
- When ECS does take over rendering, route child rendering through
\Elementor\Frontend::render_element( $child ) (or the equivalent canonical method in the active Elementor version) so that all third-party filters registered against elementor/frontend/widget/before_render, elementor/frontend/container/before_render, and elementor/widget/render_content continue to fire for those children.
- As an additional safety net, you could expose a filter such as
ele_custom_skin/should_process_container that other plugins (or site owners) can use to opt a container out of ECS processing.
Impact
Because this affects every container site-wide, it silently breaks any plugin that relies on Elementor’s standard render filters to control output. Display Conditions is the most visible victim (hidden content becomes visible everywhere), but the same architectural issue would affect any plugin doing conditional rendering, dynamic content gating, role-based visibility, A/B testing, or geo-targeting at the render layer.
Thank you for reporting this and for the detailed root cause analysis.
You are correct. The Container Layout module registered add_filter( ‘elementor/frontend/container/should_render’, ‘__return_true’ ) unconditionally, forcing every Elementor container to render and overriding third-party conditions, including Essential Addons conditional display.
The fix is now in: the filter is replaced with a conditional check that only forces rendering on containers that actually have an ECS slider or custom layout mode set. Plain flex and grid containers now respect the original should_render value, so EA conditions work correctly again.
The fix will be in the next release. Thank you for taking the time to dig into this.
