Divi: Breaking up is never easy

October 30, 2019 | Divi, PHP, Wordpress | 3 comments

As a true Divi aficionado and a Facebook procrastinator I read a lot of stuff online and often feel the need to comment and either help out or remind people that the problems they are having are in fact PEBKAC. On some posts though I feel the need to branch out and explain my thoughts in more detail via a blog post. This is one of those days.

A while back (Dec 2017) I wrote a plugin called Bye Bye Divi which acted to remove all shortcodes from your content when moving to another theme or page builder. It simply removed the shortcodes to avoid you doing it manually before rebuilding your pages elsewhere. I saw a post today whereby a Divi customer with several large sites was considering the implications of moving away from Divi and the mess it would cause on their sites. His concerns are not unfounded though.. he has a point!

How hard is it to move away from Divi when you have made the decision to use another builder or to go to something like Gutenberg. The answer of course is that it’s incredibly difficult, more-so for larger sites. Divi uses shortcodes in the content to generate the module output and to store settings. This is fairly normal of most builders. The difference here is that Divi has a lot of modules, both third party and code, that would need to be converted/removed in the event of a move.

There is, however, a simple solution. A couple of weeks ago that would have been to use my Layout Injectors but I would now say that using the Divi 4 Theme Builder has the same effect. Both options today are viable and acceptable to save a lot of pain moving forward.

Let me explain…

The process of adding a post/page/product/anything to the site using the Divi builder will generate shortcodes in your content, we know this.. it’s why we’re here. Divi has offered the ability to design your own Blog Posts in the builder since day 1. Whilst this is lovely for pretty posts it is completely unsustainable for any site with more than a few sites or for those devs who repurpose the ‘post’ post type for things like case studies and projects (and, most importantly, where there are now and will only ever be a few items). Since I have been selling the Woo Layout Injector plugin I have been asked repeatedly by my customers to enable the builder on the ‘product’ post type so products can be designed individually. A while back ET added the ability to toggle on/off the builder on a per post type basis. The logic being that you can use the builder everywhere.

This is a bad idea!

For years I have been banging at the same drum about this. It’s why my Injector series of plugins was produced and one of my main niggles about any page builder. The best solution is to template the site using the builder. The advantage of this is that you then have fewer parts of the site to redesign on moving away to another theme or builder making life much easier. Consider this.. you have 500 blog posts, all using the builder. Move away from Divi and it’s shortcode hell. You then need to go over each post and remove the builder first and reformat it accordingly. The same can be said when want to update the look and feel of your site.. brand colour changes, sidebar changes etc.. If you use a central template such as those offered by CPT Injector or the Divi Theme Builder then you can simply set up a central template which gets applied to the content on output. This means zero shortcodes to replace ever! This approach works for products as well as long as any other post type where it’s safe for every piece of content to be laid out in the same way.

The big caveat

How many pages do you have? A page being defined as a piece of content with a unique layout. In WordPress it’s easy, the ‘page’ post type is used by 99% of sites for ‘normal’ content. In principle your homepage is going to be different to your about page which, in turn, will be different from your contact pages. When you move away from Divi you need to consider the new layout of these pages after moving. The quick method is to install the Divi Builder plugin on the new site and you can slowly convert each page to use the new builder as and when it suits you. It’s a nice way of transitioning but I can see why some people don’t like that approach.

If your site is a regular brochureware type size (5-30 pages) then converting them to a new builder isn’t a huge task. You don’t change builder every day and wouldn’t do so without consideration. It means you’re less likely to change in a hurry without looking into the effort needed and what each new builder can offer. For larger sites there are some more things to consider though. We’ve covered pages, projects, products etc but having a LOT of pages on your site is a massive nightmare regardless of your templating system. Back in the old days of WP, pre-page builders, the method was to create a template file in the Theme and selecting it on a per page basis. This worked well for small sites but page builders make things so much easier. Logically if you have ten pages then you’d need ten page designs but let’s say your site has 300 pages. In this situation would you logically have 300 page layouts? No of course you wouldn’t! In fact the larger your site the more chance of duplication of layout/design. This gives us some choices.

Split down

Split our 300 pages into smaller groups of pages in different WP post types. Logically if you had so many pages then there would be some grouping. You may have used pages for Contact pages, FAQs, Press Releases in which case split them out into their own post types and template the items accordingly. This is really the best approach as often the reason for having so many pages is a bad structure in your content. Spend some time thinking about which pages should actually be pages and which could be split out and then you’ll make your site easier from an administration perspective and also it’ll be easier if you choose to move away.

Template via the theme

If your pages are templated according to their position in the page tree then you are in a tricky situation with Divi. For larger info sites where there are a lot of pages in a hierarchy then you may wish to have your content laid out differently at the top level to the layout a level below or at the third level (and so on). This method, to me, would be done at child theme level and I would use generic layouts for the internal pages but you can be forgiven for using the page builder to make each page in this way. In this situation I’d be looking to write custom logic into my templates and then using library layouts from the PHP. If it’s too late and you’ve done it like this already then consider the templated approach as a matter of maintenance and then convert your pages back to text only in your own time. If you’re moving away from Divi then this is just one of those jobs that will need to be done. It won’t be fun but a necessity.

Anything else

Sadly you’re out of luck here. You chose to design all of your pages individually which is ok but on moving away from Divi you should look to convert them to the new builder quickly. If there are a lot of these then my aforementioned advice comes into play. Set up the Divi Builder plugin and the new builder plugin at the same time (don’t worry it works!) and then convert the pages in your own time.

Final thoughts

Anyone can buy Divi and make a site but not anyone is capable of analysing the needs of a site as it grows. You should have a friendly and capable Divi aware developer on board to help you through the process. It may cost a bit of your hard earned but in the long run it will pay off. The vast majority of sites, especially those using page builders will be small corporate brochureware sites, blogs or shops. Any these will never cause any problems. Anything bigger or more complex then I’d still be ok using Divi but perhaps consider your template structure, page hierarchy, custom post type usage and build the site the ‘right’ way from the outset. That way if you ever want to move away from Divi then it’s no big deal. That said I do enjoy using Divi and sites I’ve built more recently I have used the *new* visual builder which is far more bug free than the original VB release and much more satisfying to use than in the past. The theme builder is also welcomed by the community and despite it killing a proportion of my plugins which directly effects my business, I can’t complain about it at all. It’s a lovely feature to have built in and heralds the start of the next phase in the Divi ecosystem.

To those people who say that Divi or WordPress isn’t capable or handling sites over X pages they are sorely mistaken. I manage WP sites with 7000+ pages without breaking a sweat. WP is the tool for the job and Divi just embellishes that making life easier.

A Donate Button!


  1. Dehn Merrill

    Nice work Sean. And good points all.

    Thank you for the read and for the couple thoughts I had that I need to consider myself. Best Always!

  2. Steve

    Well said Sean,

    We have 1 site in Extra that currently has 15,000 pages and posts, over 25,000 images and it is still going strong. The site started on one of Elegant Theme’s first ever themes and has evolved as they have evolved.

    We created our own form of injector specific to the site, but wish your toolkits had been around before we did this work!

    Evolution in the DIVI ecosystem will never stop, and we thank creatives like you that see the gaps, and fill the, no matter for how long. Thank You!

  3. Manuel

    Completely agree with Sean (and, by the way, nice job with your plugins!).
    I’ve spent some time to migrate huge and complex site, built with Divi + Toolset/Toolset Views, but the point was: the migration was in fact not so difficult, because Toolset has allowed me to build the entire site with a template for header/content/footer/page section, avoiding me to fill the site of shortcodes.

    The full story is: When Divi 4 has come, sadly, the site broken due to the complexity of some parts, with data taken from related/child/parent post (and Divi with it’s integrated dynamic fields support was unable to accomplish the task, it’s why Toolset was fundamental to build that site).
    So, Toolset support tells me that they are aware of the situation but the source of the problem is lying in the deeps, where the post loop lives and where Divi changed something important with dealing with it.

    I’ve decided, sadly, to switch to another very famous builder, which name starts with… a vocal letter ūüėČ

    With this in mind, starting from now and for a certain time, I will relegate Divi to completely different site projects, because I don’t want to rebuild a site again from the basics because ET changes the behaviour of the builder regarding the post loop, the very basics of WP.

    Maybe I’m wrong, I’m not a full stack developer so I can’t verify myself how Divi changes it’s behaviour since version 4 (but I think that, with some time, PHPconsole can help me understand this) , but from my point of view, when a theme doesn’t play well with the existing ecosystem of tools (and Toolset isn’t a small player!), the problem lies in the theme, and not in the ecosystem.


Submit a Comment

Your email address will not be published. Required fields are marked *

CommentLuv badge

Stay in touch!

Page Builder Cloud

Page Builder Cloud

A truly universal template library for WordPress Page Builders.

Page Builder Recommendation

Elementor Banner

We are BIG fans of the Elementor page builder. Give it a look!

About this site and Sean Barton

Picture of Sean
Sean Barton is a Freelance PHP Website Developer in Crewe, Cheshire. He is a Wordpress and CMS/Framework specialist and Co-Founder of Page Builder Cloud.
This site was set up in 2008 as a tutorial and scripting resource for the PHP language and Wordpress.
Find out more about Sean on the About Me page or use the Hire Me page to get in touch. For more information about Sean's work take a look at the Portfolio

Our Services

  • Wordpress plugin/theme development
  • Divi specialist
  • Ecommerce (Woocommerce, WPSC, Shopify, Magento)
  • PSD to Wordpress theme conversion (Responsive)
  • Website design work (Banners, Logos, Full Site, etc)
  • Website analysis (security, usability, SEO)
  • API Integrations (InfusionSoft, SalesForce, Ontraport, Customer Thermometer, etc..)
  • Wordpress consultancy & expert advice
  • Crisis support
  • Website hosting

The main services offered are Wordpress based although we do a great deal of technical programming for bespoke systems. From troubleshooting, extending frameworks, finding bugs to writing them from scratch.

Find out more by looking through our past projects or get a quote.

Be the first to hear about new products/updates!

This is a mailing list for those people interested in being told when we release a new product (Divi plugin or Theme).

We shall also use this list to let you know about product updates and releases.

You have Successfully Subscribed!