Elementor Editor — B2C, Popular and On-Prem

Working in Elementor on the Website Editor product is different. While the rest of the industry, such as Elementor Hosting, is hard at work on SaaS, the Editor is "On-Premises". Versions don't get updated on any release, but live forever on servers that refuse to update. Similar to how your phone or computer asks you, not very politely, to update your system, the user has the choice, and millions of users often pick: "not now".

Previously, I would work hard on a feature, only to have no one actually use it, or never hear about it again except for bugs.

Now, when I release a new feature that my team and I worked on, Elementor being a popular B2C product, people make YouTube videos about it! They openly criticize product decisions and bugs on social media, and are even passionate enough to go over the source code and tease upcoming features!

In the past 1.5 years, everyone at the Editor Group has been working hard on the release of the new Editor V4. Providing massive changes from Atomic Elements, Components and many other features compared to V3 version.

The Editor V4 Prop Type System

Data previously schema-less in V3 is now persisted with types, making data read and write safer and easier.

As a major improvement to old schema-less data, developers and 3rd party contributors now know the structure of the data while developing!

New code, written in TypeScript, is easily added and checked at compile time, no longer giving out runtime errors that data doesn't match the code, such as the dreaded: TypeError: Cannot read properties of undefined

This also makes it easy to sanitize and validate data, since you know what you expect to get and can avoid persisting trash data.

The data is read from database deserialized into objects according to its schema, and used across the system.

Beta Release

As we approached the beta release, everyone was on edge, tasks needed to be polished, and content that wouldn't make it properly needed to be cut.

We stepped up our testing, no more alpha mode. The system now has to be stable!

My team received a critical ticket — When downgrading versions, the entire editor breaks.

Breaking changes bugs weren't uncommon in an alpha environment, but it was unusual for QA to catch something so severe, so late. Tests and developers working on a shared version often see these issues beforehand.

Just Another Ticket

Well, I started investigating.

This was a critical bug that broke the entire editor with seemingly random uncaught errors.

I followed the Steps to Reproduce, and as many of us devs do, called the QA and told him: "For me, it works!".

After debugging for a while with the QA, we managed to reproduce the bug on my local system.

I discovered the root cause of the issue, then it hit me: this has the potential of breaking every site running on the new already alpha released V4 Editor, only a few weeks before beta release!

To make matters worse, this wasn't a fixable code issue, this was an anti pattern in our entire Prop Type system, that we didn't consider until now.

The Problem

When a user works on their site using Editor V4 and "publishes" a page, it wraps all the different "site settings" in a JSON template and saves to database for persistence.

On load, this data contains all the metadata we need to create content from edit mode to a real web page.

When loading a page, the persisted data is fetched from database, then in runtime compiled into HTML / CSS / JS, everything you need for a web page!

In runtime this passes through the Prop Type system that turns raw data into typed objects.

Imagine the following scenario: 1. Developers change schema of the "Color" type in the next release, it now looks like:

old schema
{
  "$$type": "color",
  "value": "#008000"
}
new schema
{
  "$$type": "color",
  "value": {
      hex: "#008000",
      text: "green",
  }
}

2. The user is running on the latest version, they publish page, and save color settings 3. In their database, color exists in the old schema 4. The user updates version, with color changed as new schema 5. In the database, color is unaffected by recent version changes and remains saved as old schema 6. The user enters site, and data is loaded: Chaos in our once structured system! All the code that expects everything to run according to a schema breaks at runtime at unexpected locations.

Now What?

With the release drawing near, no clear and immediate solution, and table full of high priority tasks. What would you do in my position?

If I was working on a SaaS product, the answer is easy!

Write database migrations. All the data is under my control, and I know everyone is running on the code version that I release.

But in an on-prem environment, none of that is true.

Every customer has his own internal database, and customers are running on wildly different versions, moving UP and DOWN unexpectedly between them.

If you're curious about the solution and architecture see my next article: Writing Schema Migrations for an On-Prem Product