Divi WordPress

Opening your Divi Header and Footer icons in a new window.

A few weeks ago I released the Atlantic Wave Social Media plugin for Divi. The plugin extends the built in Divi header and footer social media icon set by adding up to 13 additional social media icons.

A customer recently asked me how it would be possible to open the social media links in a new window. Now I will probably release an update to the plugin to add this functionality, but for now I thought it would be a good idea to share a simple way of being able to do this. Even if you don’t use my plugin, being able to set your social media icons to open in a new window is a good practice.

By adding a little piece of JavaScript to your Integration tab in the Divi Theme Options, you can set the social media icons to open in a new window.

  1. In your WP admin, select Theme Options from the Divi menu
  2. Click on the Integration tab
  3. Make sure ‘Enable body code’ is enabled.
  4. Scroll down to the section where it says ‘Add code to the <body> (good for tracking codes such as google analytics)’
  5. Add the JavaScript code snippet below. If you already have some JavaScript there, you can just put this inside the existing <script> tags. If there is nothing there then make sure to wrap the JavaScript with <script> tags.
    $('.et-social-icon .icon').each(function(){
        $(this).attr('target', 'blank');

And there you go, all your social media icons should now open in a new window!

Development Divi WordPress

Make your Divi Page Builder go large.

I tend to prefer to use the full extent of whatever screen I am on to it’s fullest effect. Typically I have two screens, my 23inch widescreen monitor and my 17inch laptop screen. The monitor is for coding and all coding related things and the laptop screen is for testing in browsers as well as the odd VLC or YouTube window.

One thing I hate is when I am working inside a modal view that doesn’t take full advantage of whatever screen I am on. This is a special pain point whenever I am using the Divi Builder, which makes extensive use of modals.

So I took a quick look under the hood and it turns out setting the modal to fill the screen isn’t that hard to do. A few lines of CSS code later and viola, Divi Full Width Page Builder plugin.

I haven’t tested this with every instance of every modal, but I’m looking forward to trying it out.

If you want to install it as a plugin, you can do so from the Git Hub repo. Alternatively copy and past the PHP code from the full_screen_page_builder.php file into your functions.php.

Happy Diviing.

Development Divi WordPress

Adding CSS to your Custom Divi Modules

Recently I posted on the topic of Building your own Divi Builder Modules. As a PHP developer first, in that article I focused lightly on the PHP side of things, how to setup the module code etc.

Michelle Nunan from DiviSoup pointed out that it might be handy to know how to add custom CSS to your new custom module. So here we go.

I am going to use the Image Overlay Module that I sell on Elegant Market Place as an example.

1) Know the code

So whatever your custom module is, when it renders on the front end it’s going to display a bunch of HTML. You could go into the module code to determine what html is being created (or perhaps you coded the HTML yourself and you already know), but the simplest way to check is to add the module to a page, preview it and inspect the HTML.

My Image Overlay module creates the following html:

<div class="et_pb_module et-waypoint et_pb_image et_pb_animation_off et_pb_image_overlay_0 et_always_center_on_mobile et_pb_image_overlay et-animated"><img class="main" src="" alt="" /> <img class="overlay" src="" alt="" /></div>

As you can see the main container has quite a few classes attached to it, but the important one is the et_pb_image_overlay class. You will notice that this is the same as the slug created in the previous article. So this means we can apply css to any instances of the et_pb_image_overlay class, or any elements inside that class (in this case the images).

For this example I’m just going to use the following CSS snippet. (it’s nonsense really, just used for an example).

.et_pb_image_overlay {
    position: relative;
.et_pb_image_overlay img.overlay {
    display: block;

I’m going to place this code inside a .css file inside my child theme under a directory called css.


The names and directory locations are just my choosing, you could use anything you like really.

1) Load the code

Now I need to tell WordPress to load my CSS. In my child theme I will probably already have something like this (if you don’t have a child theme, time to read up on how to create one)

function theme_enqueue_styles() {
    wp_enqueue_style( 'parent-style', get_template_directory_uri() . '/style.css' );
add_action( 'wp_enqueue_scripts', 'theme_enqueue_styles' );

So all I need to do is add a line to enqueue my new custom css

function theme_enqueue_styles() {
    wp_enqueue_style( 'parent-style', get_template_directory_uri() . '/style.css' );
    wp_enqueue_style( 'custom-image-overlay-style', get_stylesheet_directory_uri() . '/css/image_overlay_css.css' );
add_action( 'wp_enqueue_scripts', 'theme_enqueue_styles' );

The second line added to the theme_equeue_styles function tells WordPress to load a file located in the current theme (my child themes) css directory called image_overlay_css.css, the file we created earlier.

And that’s it, style created and loaded.

Development Divi WordPress

Building your own Divi Builder Modules

I’ve recently been spending some time extending modules in the Divi Page Builder.

I had a few requests from clients to either make changes to an existing module or create a new module with custom functionality. As always my first port of call was a Google Search. The results, while not abundant, did eventually lead me down the right path.

The limited set of articles I did find didn’t really explain the complete process of setting up a new module or they used slightly incorrect ways of adding a new module to the page builder. So I decided to write a post that detailed the entire process from start to finish. For the sake of this article, we are going to take the Image module and make a new one based on it.

This article won’t go into the details of actually customising the module, as that will be dependant on your specific needs. Also it would probably take up a whole heap of additional articles explaining all the sections in a Page Builder Module Class.

1) Preparation

First off you a basic understanding of PHP and WordPress hooks. For the sake of this article I’m going to assume you are working with a child theme. All the PHP code will be added to one of two files in your child theme. The first is the child theme’s functions.php file (create it if there isn’t one) . The second file will contain all the module related code. You can call the file anything you want, for this article I will call mine custom-pb-image-module.php.

So in the root of my child theme I will have


Inside the functions.php file, include the module file, typically at the top of the functions.php

/* include custom image module file*/ 
include(get_stylesheet_directory() . '/custom-pb-image-module.php');

The get_stylesheet_directory() function will return the path to the child theme folder.

Everything else we do will be inside the custom module file.

2) Prepare your custom module file

Inside the module file add this code:

function ex_divi_child_theme_setup() {

  if ( class_exists('ET_Builder_Module')) {

    // this is where your new module class will go


add_action('et_builder_ready', 'ex_divi_child_theme_setup');

What does this code do?:

  1. Adds a hook to the et_builder_ready action, to call the ex_divi_child_theme_setup function.
  2. The ex_divi_child_theme_setup function then checks if the Builder Module class exists and if true, runs the new module class.

2) Copy an existing module.

The ET Builder Module Classes are quite big, so you don’t really want to write the entire thing yourself. (You’d probably need to be a developer at Elegant Themes to be able to do so anyway). So choose an existing module that is closest to what you need, and then go and find it’s Class in the following Divi file:


I’m going to use the Image module, it looks like this:

class ET_Builder_Module_Image extends ET_Builder_Module {
  function init() {
    $this->name = __( 'Image', 'et_builder' );
    $this->slug = 'et_pb_image';
    // a whole bunch of PHP code that defines how the class functions 

new ET_Builder_Module_Image;

Copy the entire class of the module you want to use including that last ‘new ET_Builder’ line and paste it inside your module file, replacing the comment of ‘this is where your new module class will go’.

3) Time to do some hacking.

Firstly you need to rename the Class Name of the new module and the slug. The default Image Module class looks like this

class ET_Builder_Module_Image extends ET_Builder_Module {
  function init() {
    $this->name = esc_html__( 'Image', 'et_builder' );
    $this->slug = 'et_pb_image';

For our new module we would do something like this

class ET_Builder_Module_Image2 extends ET_Builder_Module {
  function init() {
    $this->name = esc_html__( 'Image 2', 'et_builder' );
    $this->slug = 'et_pb_image2';

Note that it is very important to keep the et_pb_ prefix for the module slug, otherwise the Divi Builder won’t load the module.

Then we need to change how the instance of the new class is called, as well as add the shortcode for it (so that WordPress can render your module on the website). At the moment it says this:

new ET_Builder_Module_Image;

We need to change it to this

$et_builder_module_image2 = new ET_Builder_Module_Image2();
add_shortcode( 'et_pb_image2', array($et_builder_module_image2, '_shortcode_callback') );

using the new class name and the new slug.

NOTE: if you want to override an existing module with a customised version (not add a new one), you only need to change the class name of the module, not the slug. Also you need to replace the shortcode for that module.

class ET_Builder_Module_Image2 extends ET_Builder_Module {
  function init() {
    $this->name = esc_html__( 'Image', 'et_builder' );
    $this->slug = 'et_pb_image';


$et_builder_module_image2 = new ET_Builder_Module_Image2();
remove_shortcode( 'et_pb_image' );
add_shortcode( 'et_pb_image', array($et_builder_module_image2, '_shortcode_callback') );


Anyway, we’re building a new module, so your final custom module file looks something like this:

function ex_divi_child_theme_setup() {

   if ( class_exists('ET_Builder_Module')) {

      class ET_Builder_Module_Image2 extends ET_Builder_Module {
         function init() {
            $this->name = __( 'Image', 'et_builder' );
            $this->slug = 'et_pb_image2';
            // a whole bunch of php code that defines how the class functions
      $et_builder_module_image2 = new ET_Builder_Module_Image2();
      add_shortcode( 'et_pb_image2', array($et_builder_module_image2, '_shortcode_callback') );


add_action('et_builder_ready', 'ex_divi_child_theme_setup');


Now you are ready to start making changes to the module’s code and build your custom module functionality.

Happy hacking…

UPDATE: During preparation of this article I discovered that my custom modules weren’t always loading into the Page Builder. I couldnt figure out why until I found out how the Divi Page Builder caching works. So make sure you check that as well.


Automattic Code Wrangler Application

My application for a position as a Code Wrangler at Automattic, the company started by WordPress co-founder Matt Mullenweg.

Good day

I’ve written this email in my head about 5 times, one for each year since 2010, when I first became aware of Automattic. Each time I never actually sit down, type it up and send it. I’ll do my best to explain why below. I apologise in advance for the length of my story, but it takes some time to explain.

Since 2006 I’ve been developing in PHP and I started blogging with WordPress in 2009. In 2011, I left full time employment to assist my wife in her family’s business. The business supplies data to estate agents and as such we work full day Saturday and Sunday until quite late. To keep involved in web development (which is my first passion) I took a position with a local development agency who were flexible enough to give me an on site position that matched my availability.

That worked well for about 4 years. However last year I decided to resign (mostly for personal reasons but mainly because I was becoming frustrated with the in-house CMS system that we worked with) and I am back to looking for a position which fits my specific availability, working remotely for up to 21 hours a week. The main reason I’ve never sent this application to Automattic was because I assumed that this would be a restricting factor.

I’m the kind of developer who,when tasked with writing a form submission script, will first spend half an hour asking other members of my team if the framework we are using has it’s own get_request_vars() type function (or looking through the docs and code for one, if no one knew) instead just using $_REQUEST or writing my own. I love solving problems through code, from making a script which converts .xlsx files to .xls for my wife (don’t ask, don’t tell) to building larger complex eCommerce stores. I have a huge respect and passion for good written documentation, so much so that I got involved with the new WordPress HelpHub project after WordCamp Cape Town 2015. I can think of nothing more exciting than building/improving a product that is used by people around the world.

Finally I believe that as a developer I am only as good as the rest of my team, so supporting my team (both in mentoring where I can or just keeping spirits high) is almost as important to me as my own work. How this passion for people would fit into a remote work situation I have yet to discover, but I’m excited to find out.

Development Divi WordPress

Divi Page Builder Cache

The latest versions of the Divi Page Builder includes very smart caching. This can sometimes lead to problems where users find they can’t add or delete rows or modules or use custom modules.

Disclaimer: I’ve only really experienced this issue when developing module customisations. So this may not work for your specific Page Builder caching situation. Results may vary.


Divi’s Page Builder uses the JavaScript LocalStorage API. Basically this allows the Builder to store the Page Builder cache on your computer instead of in your browser, meaning that even clearing your browser cache does not clear the Page Builder cache.

You can see the LocalStorage elements from your browser’s inspector window. In Chrome it is found under Resources (see image below)


To clear the LocalStorage items you need to run a line of javascript in your inspector window’s Console tab.

for(var prop in localStorage)localStorage.removeItem(prop);

I’ll expand this below so you can see what its doing.

for (var prop in localStorage) {

What this does is loop through each property in LocalStorage and remove it from LocalStorage. Simple!

UPDATE 05/11/2016 As John kindly pointed out in the comments below an even quicker way to clear the local storage would be to just clear the local storage object.


Once you’ve done this you’ll need to refresh the page to see if it has worked.

It’s worth noting that any other web apps you use that may use LocalStorage will also be cleared out, so it’s perhaps best to check if there are any other LocalStorage properties that aren’t Divi specific.

For those who aren’t as tech savvy to know where their inspector window is or how to use it, I’ve created a simple plugin that will clear all localStorage while using the WordPress admin interface if activated. I don’t recommend you leave it activated at all times. You can download the plugin here. Please note that this runs some JavaScript in your admin view, so once you activate it, refresh your admin view and leave it for a few seconds, before trying the Page Builder again.

I’d love to hear if this solved your specific Page Builder caching issues, so please leave a comment below if this helped you.

Development WordPress

5 SEO Mistakes to Avoid

A little background…

Recently I was in the interesting position where plugin I had always used started giving me some hassles.

For basic SEO functionality my go to install is the Yoast SEO plugin as it gives me the basic features I need and comes highly rated on For my first client of the year I installed the plugin and found that it gave me an issue when attempting to use the theme’s built in page builder, namely I couldn’t access it. A quick Chrome inspector session revealed a JavaScript error/conflict of some sort. Disabling the plugin caused the issue to go away.

Now normally I would simply contact either the theme developer or the plugin developer and see who was at fault. In this case I asked around and it seems there was some issue with the plugin and the theme I was using. Not prepared to change themes at this point in development I looked into an alternate SEO plugin and came across the All in One SEO Pack from Semper Plugins. A quick install later and all was well.

Now to the point of this introduction. As part of the free version of the plugin I was able to subscribe to their newsletter to receive updates and download a free SEO Tips ebook. As someone who is always keen to improve my knowledge I downloaded the book for future reading. While the books contents are valuable, my favourite part were a list of ‘5 SEO Mistakes to Avoid’.

Whether you’ve been optimizing your web pages for quite some time or are new to the strategy, everyone makes mistakes. While the bad news is that these mistakes can have a significant effect on your page ranking, the good news is, they’re reversible. Here are five SEO mistakes to avoid (And if you’ve already made them, not to worry, you can make changes and move forward with your SEO strategy).

SEO Mistake #1:

Not using keywords correctly. Many webmasters are concerned about being banned from the search engines for keyword spamming or stuffing so they limit the use of keywords on their web pages. As long as your content sounds natural and reads easily, the chances are you have not overused your keywords. Make sure your keywords are included in the first and last paragraphs, in your headings and in your title and meta tags.

SEO Mistake #2:

Trying to fool search engine spiders. Search engines are a lot more sophisticated than most of us realize. They recognize – and penalize – hidden text, keyword spamming, and cloaking, which is showing different content to the search engine spiders than to your visitors. All of these practices only serve to hurt your page ranking and can in fact cause your website to be banned by the search engines, which means no one will find you – and no traffic means no profits.

SEO Mistake #3:

Using Flash Flash is a great presentation tool and can be dramatic and effective if used sparingly. It’s particularly appropriate if you have a media related website and want to demonstrate your industry savvy. However for most website owners it’s just not necessary and can harm your page ranking. Search engine spiders cannot read content embedded in Flash files, which means they’re not recognized or indexed.

SEO Mistake #4:

Using Your Company Name (and Only Your Company Name) As a Title Tag Unless you’re branding your company name, your company name shouldn’t be the only element in your title tag. Feel free to include it, however it’s also important to use your primary keyword for each webpage title tag. This is more useful for your customers and helps the search engines identify the various pages on your site.

SEO Mistake #5:

Using A Splash Page A splash page is a web page with a large graphic or company logo, and a link to enter the site. This is an ineffective strategy for a number of reasons:

  • No keyword rich text on the page, nothing for the spiders to index.
  • Only one internal link on the page
  • These pages often have a redirect which often causes spiders to ignore them

If search engine optimization is important to your business, you may need to forgo the splash page. Your home page should be easy to navigate, content rich, and link visitors and spiders to other main web pages. In general, unless you’re trying to outsmart the search engines and using nefarious tactics, the majority of search engine mistakes are reversible. If you’ve committed a few of these mistakes, simply correcting them can increase your page ranking almost immediately. Take some time to evaluate your SEO strategy and eliminate these SEO mistakes.

Often I come across sites that break these rules and quite a few of them are also not recommended web practices but until now I didn’t realise their impact on SEO. Really valuable information for web owners and developers.

I liked Semper Plugins SEO plugin so much, as well as the information in the ebook, that I signed up as an affiliate for the pro version of their plugin. If you are in the market for a premium SEO plugin, I highly recommend All in One SEO Pro.

Experiences WordPress

Word Camp Cape Town 2015

So this year I was fortunate enough to attend my first Word Camp.

I’ve been meddling (at best) with WordPress for the better part of the last decade, I’ve set up a few blogs and sites and even completed some custom development using WordPress as the base but I’ve never been someone who was ‘focused’ on WordPress or the WordPress community. This year I decided to take a deeper look into what makes the local WordPress community tick. Boy, what a ride it was.

Day one dawned a typically early spring Cape Town day, namely rain. After getting out to the awesome venue that is the River Club, we got to mingle with some of the attendees and pick and choose our selection of ‘swag’. I wasn’t sure what the protocol was, so I just grabbed a few interesting items, my favourite of which was the USB power banks supplied by FNB/Paypal. A spread of coffee/teas and muffins awaited us while we milled around the entrance area, and then onto the workshops we went.

I chose to attend all the developer workshops and I wasn’t disappointed. From Brent’s talk on Varying Vagrant Vagrants to Pippin’s ‘Commitment to Backwards Compatibility’, each speaker was interesting, knowledgeable and insightful. I especially enjoyed Justin’s talk on the WordPress API, mainly because how interesting and funny he was at the same time, even after a 16 odd hour flight.

Day two was more of a typical conference day, with everyone seating in the auditorium, cinema style, listening to the talks of the day. Our’s MC’s were the always funny Derick Watts and the Sunday Blues who had the crowd in stitches in between each talk.

The talks on day two were just as interesting as day one, but the two that stood out for me the most were Drew’s ‘It takes a Village to make Wordpress’ and Bruce’s ‘The Age of the Digital Superhero’. Not that all the other speakers weren’t great (they were) but these two resonated with me on a personal level.

The last talk ended with the words ‘f*cking awesome’ which was apt, as this was the feeling I had when I left WordCamp. I met some amazing people and was inspired as a developer, both and a personal and a technical level. WordPress has come a long way in the past few years and it was really great to see and meet so many people who are developing, using and growing WordPress as a platform.

Special thanks go to Hugh Lashbrooke, who put all this together and was super friendly every time you chatted to him, even though I am sure he was buzzing from the nerves of running such a huge event.

And finally, thanks to all the amazing WordPress users and developers I meet, who made me realised that there is something special about belonging to an open source community.

I’ll definitely be back next year.