Blog

Breakpoint System Changes in Elementor v3.2.0

As we have published several months ago, we have been working on releasing a highly requested feature – additional custom breakpoints. Core 3.2.0 is another milestone in the road to achieve this goal AND achieve better performance overall in Elementor sites as part of the process. As detailed in our recent blog post, step one of our roadmap is:

Convert hard-coded usage of breakpoints (tablet, mobile, default) to a dynamic system that will utilize registered breakpoints (the two existing ones + future Additional Custom Breakpoints).

In essence, these changes, as well as a lot of UI changes and additions as listed in step 2, are all included in Elementor Core 3.2.0.

Elementor v3.2: Additional DOM Improvements

In Elementor v3.0, we made the first step in optimizing the HTML output of Elementor pages. One of the steps in v3.0 was removing 3 wrapper elements from the Editor’s DOM output: .elementor-inner, .elementor-row, and .elementor-column-wrap.

The Optimized DOM Output feature is optional, and is configured as an Elementor Experiment. The two new wrappers being removed are also included within this experiment and will only be actually removed from a website’s markup if the experiment is active in that website.

In Elementor v3.2.0, we are continuing our optimization efforts and removing two more wrappers:

• .elementor-image
• .elementor-text-editor
  

v3.2: Planned Deprecations

Hey all! We are getting ready to release versions 3.2.

If you are a developer who extends Elementor please review the below changes to keep your plugin up and running.

Here are the planned deprecations:

PHP

Functions & Methods

Soft Deprecation

When a function/method is in the soft deprecation phase, it means that the function/method will still work while it’s in this phase, but a comment will be placed in the code mentioning the upcoming deprecation.

New Experiment: Optimized Asset Loading Mode

In the upcoming Elementor v3.1.0, we created a new “Improved Asset Loading” mode, which reduces the amount of JS code loaded on the page by default. When activated, parts of the infrastructure code will be loaded asynchronously, only when needed.

Which Functionalities Already Support the New Improved Asset Loading Mode?

1. Widget JS Handlers

Up to Elementor v3.1.0, all widget handlers were loaded to every page by default, regardless of whether they are actually used on the page.

Starting in Elementor v3.1.0, when the “Improved Asset Loading” mode is active, each widget will dynamically load its handler, only when being used on the page.

A New Method For Attaching A JS Handler To An Element

In Elementor 3.1.0 version, we created a new method for attaching a JS handler to an element.

Up to Elementor 3.1.0, in order to attach a JS handler, we used a hook called addAction, and passed a function to it (addHandler):

const addHandler = ( $element ) => {
	elementorFrontend.elementsHandler.addHandler( ElementHandlerClass, {
		$element,
	} );
};
 
elementorFrontend.hooks.addAction( 'frontend/element_ready/your-element-name.default', addHandler );

For more details, see here.

New Developers Feature – Compatibility Tag

As part of its being an open-source project, Elementor includes an extensive developers API, enabling the creation of a vast eco-system of 3rd party extensions that build on and enhance Elementor’s capabilities.

However, there are aspects of Elementor’s codebase that are not officially exposed and/or documented in our Developer Docs. From time to time, 3rd party extension developers utilize code from Elementor’s codebase which has not been officially exposed and documented. 

This can cause problems for Elementor users who also use such extensions, in cases where such 3rd party developers do not use Elementor’s code as intended, or fail to update their extensions to make them compatible with the latest versions of Elementor and/or Elementor Pro. In some cases, such incompatibilities also result in complaints to Elementor’s support department about issues that were not directly caused by our plugins.

v3.1: Planned Deprecations

Hey all! We are getting ready to release version 3.1.

If you are a developer who extends Elementor please review the below changes to keep your plugin up and running.

Here are the planned deprecations:

PHP

Functions & Methods

Soft Deprecation

When a function/method is in the soft deprecation phase, it means that the function/method will still work while it’s in this phase, but a comment will be placed in the code mentioning the upcoming deprecation.

CSS Rendering Performance Improvement in Elementor 3.0

Elementor has two ways for rendering website CSS: 

1. Printing it in a <style> tag in the DOM
2. Writing it to a CSS file that will be loaded with the page

The CSS written to files, for example, is completely static. It is printed once into a file, and that file is only updated when a change is made to the page’s content.

But what about dynamic content? Some dynamic content includes its own CSS, such as colors and images (when used as background-image values). Dynamic content, such as custom fields, is disconnected from the page’s content, and can be changed outside of editing the post or page in Elementor Editor. So what happens when dynamic values include CSS that needs to be printed every single time a page is loaded?