Why I Eschew the Divi Theme

There are a lot of things that web designers like about the Divi theme, especially if they don't have a web development background and understand the technical nuances required to program in PHP, jQuery, and CSS. In fact, most web designers that I've spoken with don't care about the underlying code. They just want to be able to impress clients with a quick and easy build that meets the immediate visual requirements. That's why the Divi theme is so popular among designers and newbies.
Personally, I eschew the Divi theme and do everything I can to avoid any project that has anything to do with it. Why? Because I am not only a web designer, I am full-stack web developer. Whenever I've had to work on sites that use the Divi theme, I've become a first hand witness to the wake of shortcodes it leaves embedded in a site's content. Oh the humanity!
You've all seen shortcodes I'm sure. They're little pieces of text wrapped in square brackets "[this-is-a-shortcode]". When a browser accesses a page containing them, those little pieces of text are translated into some kind of computer code to display the content in various ways.
The Divi pagebuilder may insert dozens of shortcodes into every page on your site as you use its drag and drop interface to format the appearance of your content. That's not a problem as long as you commit to using the Divi page builder for the rest of your natural born life. But as soon as you decide to move away to another theme that provides upgraded professional features such as accessibility or schema.org markup, Divi refuses to let you go.
Just when you think it's safe to get into the water (Jaws theme playingâ¦), all of those dozens, hundreds, or even thousands of shortcodes are suddenly visible in your content. So instead of displaying text that reads, "Welcome to my world!", your readers will see, "Welcome to my [et_pb_Divi_is_back_to_haunt_you] world!". Not very nice is it?

There's never been an easy way to remove these shortcodes either. In most cases, the only way to remove these shortcodes has been to edit each page on the site and remove them manually. If you have just a few pages this is fine, however, if you have a lot of content built up over years, removing the Divi shortcodes is a long, laborious process that can drive the best of us a little nuttier than usual.
Now Comes the Good Part
For the past few years, I've been using WP All Import by Softlyy to migrate eCommerce data into WooCommerce. It works great and since they added Orders and Customers to the mix, the plugin is fantastic. But it's not a plugin for the faint of heart. You have know what you're doing to use it properly.
Earlier this year, the Softlyy team released a companion product, WP All Export. I am very impressed with its capabilities and decided to try it for the Original Strength project. In my first attempt, I exported the pages from the production site to see if I could import them into the development site. The Divi shortcodes kept crashing WP All Import.
The reason why is that the export file is created as a CSV with double quotes as the string delimiter and the Divi shortcodes wrap their parameters in double quotes instead of single quotes. With all those double quotes in the wrong place, things just kept getting confused.
Undaunted, it was time to press on with a hopeful feature. Both of these plugins have a built in function editor that allows you to create your own php functions to manipulate your data. I decided to write a function that would strip page content of the Divi shortcodes to see how it all could work.
First, I attempted to use the WordPress strip_shortcode function. It was an abysmal failure. Those Divi shortcodes wouldn't cooperate and laughed at my meager attempt to quash them. Next, I tried regular expression matching and came up with this little snippet:
This gem of a snippet works like a charm. It removes all content that begins with [et_pb and ends with the closing square bracket. All of the Divi shortcodes were removed from the 102 pages of content and they imported into the development site without error. Kudos to Softlyy for these great tools.


As the business world continues to shrink due to the proliferation of rapid communications through the internet and social media outlets, one area that becomes a little murky is who owns the rights to custom software? What I mean by this is that as a software developer living and working in the United States of America, my business is bound to U.S. laws. For example, determining the ownership of any custom software I create is governed by the United States Copyright Law. But what happens when I create work for foreign entities, such as enterprises based in Europe or Scandinavia? Which countryâs laws prevail in an ownership dispute? I donât know the answer to this question. I am not an attorney, have no desire to be one, nor do I want to be tested to answer this question. I develop software. I enjoy developing software. Developing software is one thing I do well. But as my business continues to grow and I serve clients from different parts of the world, I have to make it perfectly clear that unless otherwise agreed to in writing, the United States Copyright Law governs who owns the custom software I create.
