Divi or the Block Editor? A Decision You Only Have to Get Wrong Once

Two sites, same agency, same month. The first is a five-page brochure site for a plumber, built in Divi in a fortnight because the owner wanted to see his own logo on a mock-up before he signed anything. The second is a membership site with a course catalogue, built on core blocks with a small child theme. Both launched on time. Both looked right.

Eighteen months later the plumber's site is fine and the agency is cursing it, because every content change now arrives as a text message and takes an hour nobody bills for. The membership site is also fine, and takes twenty minutes a month. Nothing about Divi made the first site harder. What made it harder is that the person maintaining it changed, and the tool had been chosen for the person who built it.

That is the whole decision. Divi and the block editor are both competent ways to put a page together, and the argument between them is usually settled by preference. The part that has consequences is what each one does to your content over the next five years, and who is expected to keep editing it.

What you are actually choosing between

Divi is a theme and a page builder sold together by Elegant Themes. The builder is the part that matters: it replaces the editing surface with its own interface and its own vocabulary of sections, rows, columns and modules. You can install the builder on another theme, and the licence covers the whole product family rather than one site.

The block editor is not a product. It is the editing layer that ships inside WordPress core, and it has been the default since 5.0. Its storage format is the block, which is a piece of HTML wrapped in a comment that declares what the HTML is. That distinction sounds academic until you try to move a site, and then it is the only thing that matters.

Both can produce the same page. One of them is free and one is not, which is the least interesting difference between them, because the licence is small compared with the cost of changing your mind later.

A lapsed licence stops updates, not the site

The most misreported fact about Divi is what happens when you stop paying. The site does not switch off. The themes you already downloaded keep working, and the FAQ on Elegant Themes' own pricing page says exactly that: when a subscription is cancelled the account stays active for the remainder of the one-year term, after which you lose the members area, new theme releases, theme updates and technical support, and the themes already downloaded remain usable indefinitely.

Read that as three separate losses. You lose support, which matters if something breaks during a WordPress release and you want the vendor to fix it. You lose updates, which is the one with security attached to it, because a builder and its theme are code running on every request. And you lose new features, which is the loss most people notice last and care about least.

What you do not lose is the layout. The site keeps rendering, keeps its design, and keeps accepting edits in the builder. That is the honest answer, and it is also why "you'll be locked in" is a weaker argument against Divi than its critics make. The lock-in is not that the site stops. It is that the site freezes at the last version you were entitled to, and resumes only if you pay again.

Elegant Themes sells Divi as an annual licence at Elegant Themes' pricing page, where the Divi Yearly plan is $89 billed yearly, which includes the builder and the theme and covers unlimited websites. The same page offers a lifetime option called Divi Lifetime at a one-time payment, which removes the annual renewal and the update cliff with it. If you are building client sites that you intend to hand over, that distinction is worth more than the yearly price difference suggests.

On the core side there is no licence to lapse. WordPress is GPL, the block editor ships with it, and the trade is that you own the maintenance instead. Somebody has to keep core, the theme and every plugin updated, and on a block theme the theme is often the smallest part of that job.

Content is stored in two incompatible dialects

Here is the part that decides migrations. Divi 4 stored a page as shortcodes inside the post content. A text module in the database was a tagged block of text with a long list of attributes, and WordPress core expanded it at render time because the builder registered a handler for the tag.

[et_pb_text _builder_version="4.27.0" _module_preset="default"
 background_color="#E02B20" text_text_color="#FFFFFF"]
The paragraph the client actually wrote.
[/et_pb_text]

Divi 5 changed that. Its migrator converts supported modules into a format Elegant Themes describes as not using shortcodes and instead resembling the block editor's storage. The markup is an HTML comment whose name begins with wp:divi/, followed by a JSON attribute payload describing the module's decoration and content, and a closing comment that ends it.

<!-- wp:divi/text {"builderVersion":"4.27.0","modulePreset":"default",
"module":{"decoration":{"background":{"desktop":{"value":{"color":"#E02B20"}}}}}} -->
The paragraph the client actually wrote.
<!-- /wp:divi/text -->

So the honest statement of Divi's storage story is that it has two of them, and which one a page uses depends on when the site was migrated. That is not a criticism, but it changes what you can promise a client about portability.

Detection is a query, not an opinion. Before you promise anyone a migration, ask the database which dialect the site is in.

SELECT ID, post_title
FROM wp_posts
WHERE post_status = 'publish'
  AND post_type IN ('post', 'page')
  AND ( post_content LIKE '%[et_pb_%'
     OR post_content LIKE '%wp:divi/%'
     OR post_content LIKE '%wp:paragraph%' );

Escape the square bracket if your SQL dialect treats it as a wildcard character, and run the three tests separately if you want to know which one is winning. A site that returns rows for the first test only is a Divi 4 site. One that returns rows for the second is already on Divi 5's framework. One that returns rows for the third has at least some content that does not depend on a builder at all.

For the migration itself, there is no supported route from Divi layout to core blocks that preserves the design. There are plugins that convert pages approximately, and they produce approximately the same page. What survives with certainty is the text, because the text is inside the shortcode or the JSON either way. What does not survive is the layout, the module presets and the Theme Builder templates that wrap the content, which on a real site are often where most of the work was.

Migration from Divi 4 to Divi 5 is a different and easier story, because Elegant Themes supports it, runs it at the database level, and recommends doing it on staging first. Note the caveat they publish alongside it: modules not yet supported continue to run wrapped in the Divi 4 framework, and a page that contains one of them loads that framework for the page. On a site with third-party Marketplace modules, the migration is where the next support ticket comes from.

Core blocks have their own limits. A block theme change can move every layout on the site, and you cannot design for a theme you have not seen. But the content stays in post_content, in a dialect WordPress core reads, with no licence and no theme required to render it. The text you wrote in 2026 is still text in 2036.

The editor experience decides who you have to keep paying

For someone who is not a developer, Divi is often the more capable editor on the first day. It is visual, the module panel is discoverable, and there are thousands of layouts to start from. The cost is a second interface to learn, sitting on top of WordPress, so the client learns Divi's dashboard and the WordPress admin at the same time.

The block editor is the opposite trade. There is less to learn because there is no separate product, and the things a client breaks are more recoverable, since a block is just HTML and a bad one can be removed without leaving the design system in a strange state. It is also the editor that gets the most third-party documentation, which is what a client's next developer will search for.

The failure mode I would watch for is not either editor. It is a site where the editing path only exists on the machine of the person who built it. If the client's contact is a phone number and the number belongs to one freelancer, the licence is not the lock-in. The relationship is.

Which one to pick, and where the advice runs out

I would use the block editor for a site that has to outlive the arrangement that created it: a brochure site, a blog, a documentation site, anything where the client will change words and images rather than layout. Use it with a block theme you are prepared to maintain, and keep the child theme small.

I would use Divi when the client is the one who wants to design. If the person paying for the site intends to build pages, restyle sections, and run campaigns without calling anyone, a builder gives them that in a way core blocks do not yet match for a non-developer. The same argument applies inside a busy agency, where the builder's layout library is the reason a landing page ships in an afternoon.

Where the advice runs out is the middle ground. A site with twenty pages, a client who edits twice a year, and an agency that will not be around in three years does not need either argument. It needs whichever option the next maintainer can open, and the next maintainer is the person to ask. If nobody can answer that question, the block editor is the safer default because the replacement cost is lower and the licence cannot expire.

What to do on Monday

1. Write down who will edit the site in year three, by role rather than by name. If the answer is a person who is not a developer, that answer picks the editor.
2. For any existing site, run the three detection queries and record which storage dialect each page uses. A migration estimate that ignores this is a guess.
3. Open the pricing page and read the renewal line on the plan you are considering, plus what the FAQ says happens if you cancel. That paragraph is the contract.
4. If you choose a builder for a client, put the renewal date in the handover document and say in writing what stops when it lapses: updates and support, not the site.
5. If you choose core blocks, decide this month who owns core and theme updates. Nobody owning it is the failure that shows up two years after launch.