Elementor Developers Blog

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.

(more…) Read More »

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:

(more…) Read More »

How to (Properly) add a Repeater control to your Custom Elementor Add-On

Elementor has a special type of control called a Repeater, which can contain other controls.
Repeaters create sub-items that are usually duplicatable, deletable, and can be used for any element which includes repetitive functionality, such as list widgets (Price List, Icon List) and Carousels (Media Carousel, Reviews).
This blog post will explain and demonstrate how to create and use repeaters – the right way.
We will take a look at and analyze the Icon List widget, which is a very clear example of creating and using a repeater properly.
Repeaters are created in the register_controls() method, along with all of the other widget controls.
To create a repeater, initialize an instance of the Repeater class:
$repeater = new \Elementor\Repeater();

(more…) Read More »

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?

(more…) Read More »

v3.0: Planned Deprecations

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

Elementor 3.0 will introduce many changes to the way our users build websites with Elementor, and the way Elementor operates.

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

Elementor 3.0 is a major release. We took the opportunity to introduce substantial changes and improvements to the infrastructure of Elementor.

Here are the planned deprecations (last update – 09/06/2020):

(more…) Read More »

DOM Improvements Ahead! HTML Wrappers Removal from v3.0

We are always looking for new ways to improve the speed and performance of Elementor websites.

This has been a long time coming. Lately, we have been receiving feedback from our users about the large number of wrapper elements we include in the HTML output of the website builder. The feedback stated that many of the wrappers are not necessary, and they increase the size of web pages and harm performance.

The presence of these wrappers is due to the diverse use of Elementor, the ability to use these selectors in various ways to customize your site, and the omni-purpose of Elementor as a solution for creating advanced websites visually.

Removing wrapper elements from the DOM contributes to more simplified code output, better readability and less complexity. A smaller DOM contributes to increases in speed and performance.

** Warning: Breaking Changes **

We have wanted to address this issue for a while now, and Elementor 3.0 provided us with the perfect opportunity to do so. Elementor 3.0 will bring many changes to the way our users build websites with Elementor, and some of these changes, including the removal of several HTML wrappers from our code, are potentially breaking. This means that when you update the Elementor version in your website from 2.x (or even 1.x, for some very out of date sites) to Elementor 3.x, your website’s appearance and/or functionality could break.

Interested in the changes coming down the road? Read more here

The Wrappers Being Removed

Without further ado, here are the classes of the wrappers being removed from Elementor in Elementor 3.0:

(more…) Read More »

v3.0 Updated Convention: Creating New Widgets (For Improved Performance)

As part of our effort to simplify and minimize the markup created by Elementor, we have decided to truncate the prefix we use for any Elementor CSS classes, from .elementor- to just .e-.

This move is joined by another important step in our journey of performance enhancement – reducing the number of wrapper HTML elements used by our widgets and by the system in general.

What does it actually mean?

In all of our new widgets, controls, and all-in-all system markup, we will be prefixing all of our classes with .e-.

We will NOT be changing pre-existing widgets, controls, or any other system elements, in order to allow for backwards compatibility and avoid causing serious problems in existing Elementor websites.

As opposed to the wrapper removal step, this is not a breaking change, so it’s not a big deal – if you see a change in our conventions, we just wanted you to let you know that it’s legit and share with you the reasoning behind it.

How does this affect me as an Elementor user or extension developer?

First of all, there is no need for you to make any changes to pre-existing widgets or system elements. If you are developing extensions that manipulate existing system elements, controls or widgets, and used the .elementor- prefix before – we recommend you to follow this guideline and start using .e- instead in your new developments.

Read More »

Elementor is Officially Dropping Support for Internet Explorer in v3.0

Elementor officially supported Internet Explorer 11 for front-end display (excluding the Editor) up until version 3.0. Starting from Elementor 3.0.0, it will no longer officially support IE 11 at all, not even for front-end display.

Why are we doing it?

Web standards and technology are constantly evolving, providing web developers with more features and better technology for creating websites and web applications. Modern Browsers like Google Chrome, Firefox, and even Edge (now Chromium-based), are constantly evolving with it, constantly being updated and improved upon. Do you know what’s not evolving, at all? Internet Explorer. Internet Explorer browser is old and outdated, and even Microsoft themselves say that using Internet Explorer is highly unrecommended. In addition, less than 3% of web traffic comes from IE browsers.

Why now?

Elementor has been already gradually introducing new widgets and features that utilize Modern web technologies and tools such as CSS Grid and CSS variables. In order to provide our users with a better experience using Elementor, as well as the ability to build faster, better-performing websites with more advanced features, it was inevitable that we would have to drop IE support completely, in order to proceed in the right direction.

How does this affect me?

If you or your target audience don’t really use Internet Explorer, this should not affect you at all.

However, If your target audience includes a large portion of Internet Explorer users, it might be a good idea to consider holding off on upgrading Elementor and Elementor Pro to v3.0.0 until you’ve made sure you have solutions that enable your site visitors to use your website conveniently.

Users who already upgraded don’t need to worry, simply use Version Control tool to downgrade back to an earlier version and everything should work as it used to.

Read More »

URI Protocols Handling Update

Elementor has now updated the way it handles URLs in the URL control.

From v2.9.11 and on, Elementor will use the use wp_allowed_protocols() function to handle allowed URI protocols in links. These protocols are often used to create a deep-link (i.e. a direct link to an app via unique protocol) to a 3rd party application (such as mailto: or tel:)

This means that from this version, only protocols allowed by this WordPress function will be available.

Examples of allowed URI protocols: mailto:, tel:, sms:, etc…

If you wish to add another protocol to your website, you will need to alter the function that retrieves the list of allowed protocols, and add your own protocol.

function allow_additional_protocol( $protocols ){
     $protocols[] = 'my-protocol';
     return $protocols;
add_filter( 'kses_allowed_protocols' , 'allow_additional_protocol' );
Read More »

Swiper Update to 5.3.6 & New Wrapper Class

In Elementor Core 2.9.0, we integrated an update to the Swiper.js library used in all of Elementor’s carousels (Core and Pro). Up to 2.9.0, the included Swiper version was 4.4.6. In Elementor 2.9, the Swiper library was updated to version 5. This version includes potentially breaking changes. Please read on for more information.

Why Did We Update?

As part of standard maintenance, we update our external libraries from time to time, including Swiper. Swiper 4.4.6 was released in December 2018, and many issues and features were added in the current 5.3.6 version.

Major Changes From Swiper 4.x

The biggest change, for Elementor, which was introduced in Swiper 5.0, was an inversion of the library’s breakpoints system. Up until Swiper 5.x, the breakpoint system worked on a max-width basis: meaning, for a given breakpoint (say, 768px), a given setting would be implemented on all screen widths under 768px.

In Swiper 5.x, the library author changed the breakpoints system to work on a min-width basis. Meaning, for a given breakpoint (e.g. 768px), the given setting would be implemented on all screen widths above 768px. There used to be an option to actively invert the breakpoint system (an optional parameter), but the library author removed that option for reasons unbeknownst to us.

It is important to understand – this is a breaking change for anyone using the Swiper library for their custom widgets. Please read the entire article in order to be sure you take the necessary action to keep your Elementor add-ons working properly.


Read More »

Never miss an update
Subscribe to our developer’s newsletter for every latest update