Hooking into the onclick event of buttons in Divi

In the Divi Theme Users & Elegant Marketplace group, Brett Bumeter asked, “anyone ever find a quick way to add an onclick event to a Divi Button?”

More specifically, Brett needs to replicate the onclick event on a regular html button, but using a Divi button.

<button onclick="myFunction()">Click me</button>

First thing we need to do is look at a Divi button’s html.

<a class="et_pb_button  et_pb_button_0 et_pb_module et_pb_bg_layout_light" href="">Button</a>

So a Divi button is really just a styled anchor tag. That’s fine, we can use the onclick event on an anchor tag. However we can’t edit a Divi button’s html, so we can’t add a function to the onclick event. What we can do is use some jQuery to bind a function to the anchors onclick event.

Here’s what that would look like:

$(".et_pb_button").on("click", function(){
    alert("Button clicked"); 

So what this does is bind to the onclick event of any element that has a class of “et_pb_button”, prevent the default action of that element (in this case opening a url) and then performs whatever functionality you need (in this case showing the alert).

Pretty simple really. You can use this Javascript snippet in a child theme as is, or you can insert it into the Divi Theme Options -> Integrations -> Add code to the < head > of your blog’ area. If you are going to go the second route, you will need to wrap the snippet above in a document ready enclosure and some script tags, like so

jQuery(function ($) {
    $( document ).ready(function() {
        $(".et_pb_button").on("click", function(){
            alert("Button clicked"); 

You could also take this a step further, and use it to pass some data to the onclick event, by using a custom button id or class. Let’s say we give the button a custom id of ‘1’.

$(".et_pb_button").on("click", function(){
    var id = $(this).attr("id");
    alert("Button " + id + " clicked");

In this instance the custom id of 1 would be passed to the ‘id’ variable, which could then be used to call some other function, which needs that value.

Happy Diviing.

Using anchor links to open accordions and tabs in Divi – from another page!

The most popular article on my blog so far (by way of comments on it) is the one on Using anchor links to open accordions and tabs in Divi. It’s so popular that when the demo page broke recently I even had a few people comment to ask if the process still worked with newer versions of Divi (it does, by the way).

It being the most popular article, the most popular question I get about it is “How do I link to and open an accordion or tab, from an external page?”. Well, today I share that solution.

Before we begin – This article is going to be a little more advanced than my usual Divi posts. This is because it is going to require delving into the world of PHP and WordPress action hooks. For the purposes of this article I am not going to delve too deeply into those topics, so I do suggest reading the relevant documentation on WordPress.org. Also, for the purposes of this article, you are going to need to know how to include PHP into your WordPress site (either via a Divi child theme or a plugin). If you are new to PHP I recommend reading my Child Theme series, especially the article on Making child themes part of your development best practice. For this article, we’ll use a child theme, because it’s the easiest way.

Ok, all caught up? Good, let’s begin!

Preparation: Understand Query Strings

The first thing you need to understand is query strings. Query strings are not something you see a lot of lately (as pretty permalinks are the norm) but they are what existed before permalinks were made popular. Query strings look something like this:


See how I am specifying that post_name is equal to my-cool-article after the question mark sign? This is a query string. In this string I am passing the variable post_name and giving it a value of my-cool-article. Once the url before the query string loads (in this case just the home page of the domain) I can check for that variable using the global PHP $_GET variable array and, if it exists, do something with it.

$passed_post_name = $_GET['post_name'];
// do something with the $passed_post_name variable

In order to open a specific tab or accordion on page A from page B, I need to setup my anchor links on page B to point to page A, but those links should also include a query string variable, in this instance the name of the accordion or tab item I want to open.

So, for the purposes of this topic my query string will something look like this




You’ll see that I am passing the class identifier of the accordion or tab item to open as the value. (more on this later)

Step 1: Making some jQuery changes

Let’s first take a look at the accordion ‘open’ snippet I posted in the original article:

jQuery(function ($) {
  $('#open-accordion-dance a').on('click', function(event){
    $('#my-accordian .et_pb_accordion_item_1 .et_pb_toggle_title').click();
    $("html, body").animate({ scrollTop: $('#my-accordian').offset().top }, 1000);
  $('#open-tab-dance a').on('click', function(event){
    $('#my-tabs .et_pb_tab_1 a').click();
    $("html, body").animate({ scrollTop: $('#my-tabs').offset().top }, 1000);

The important thing to look at is the css class identifier for the accordion or item we’re triggering the click on, in this case .et_pb_accordion_item_1 or .et_pb_tab_1. See how this is the same as the value being passed in the query string above. What we need to do now is to be able to specify that value as a JavaScript variable somehow and pass that variable into the JavaScript, to trigger the click of our selected accordion item, when the page loads.

The second thing we will need to do is make sure that this code only fires, once the entire document has loaded. Currently it waits for you to click a link on the same page, but now we’ll be loading the page with the accordion or tab content and then triggering the click.

The change to the JavaScript looks like this:

jQuery(function ($) {
  $( document ).ready(function() {
    // accordion
    if (typeof openers.accordion !== 'undefined') {
      var accordion_element = '#my-accordian .' + openers.accordion + ' h5.et_pb_toggle_title';
      $("html, body").animate({ scrollTop: $('#my-accordian').offset().top }, 1000);
    // tab
    if (typeof openers.tab !== 'undefined') {
      var tab_element = '#my-tabs .' + openers.tab + ' a';
      $("html, body").animate({ scrollTop: $('#my-tabs').offset().top }, 1000);

Note how I have changed the et_pb_accordion_item_1 and et_pb_tab_1 to openers.accordion and openers.tab and instead of those variables being inside the class selector string they are being concatenated to the string (see, I told you this was a little more advanced). I’m also wrapping the entire thing inside a $( document ).ready(function() {} and removing the on(“click”) event handlers and checking if there is an instance of either openers.accordion or openers.tab. If either exists it will fire the relevant ‘open and animate to’ code.


Step 2: Mix in some PHP

Right, so now that we have this updated JavaScript we need to setup those openers variables, based on the query string. Do to this we need to do two things a) enqueue the JavaScript in the child theme and b) pass some PHP variables to the JavaScript. To achieve this we’ll put all our PHP code into a functions.php file of a child theme.

Instead of using the Divi Theme Options Code Integration tab for the JavaScript, we need to save it in a file in our child theme and hook a function into the wp_enqueue_scripts action hook (the same one used to enqueue child theme CSS). It looks something like this:

function my_theme_enqueue_scripts() {
wp_register_script( 'some_handle', 'path/to/myscript.js' );
wp_enqueue_script( 'some_handle' );
add_action( 'wp_enqueue_scripts', 'my_theme_enqueue_scripts' );

We also need to make the PHP variable available to the script. This is done by using the wp_localize_script function, which allows you to pass any variable from PHP to the JavaScript script you are enqueuing using wp_localize_script.

function my_theme_enqueue_scripts() {
    wp_register_script( 'some_handle', 'path/to/myscript.js' );
    $variable_array = array(
        'my_javascript_variable' =&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt; 'some value'
    wp_localize_script( 'some_handle', 'javscript_object_name', $translation_array );
    wp_enqueue_script( 'some_handle' );
add_action( 'wp_enqueue_scripts', 'my_theme_enqueue_scripts' );

What this does is pass a PHP array of variables ( $variable_array  ) into the JavaScript layer as a JavaScript object ( javscript_object_name ) and makes them available to use in the JavaScript layer.

Finally we’ll need to capture the variables passed from the query string. That looks something like this:

$variable_array = array(); 
if( isset( $_GET['et_open_accordion'] ) ){ 
  $variable_array['accordion'] = $_GET['et_open_accordion']; 
if( isset( $_GET['et_open_tab'] ) ){ 
  $variable_array['tab'] = $_GET['et_open_tab']; 

There are also some other things we need to setup, like defining path urls for enqueing files and setting up the Divi parent stylesheets. Again I’m not going to go into too much detail, but the final functions.php file looks like this:

define( 'PARENT_THEME_URL', trailingslashit( get_template_directory_uri( ) ) );
define( 'CHILD_THEME_URL', trailingslashit( get_stylesheet_directory_uri( ) ) );

function divi_child_theme_enqueue_styles() {

	$parent_style = 'divi-style'; // This is the 'parent-style'.

	wp_enqueue_style( $parent_style, PARENT_THEME_URL . 'style.css' );
	wp_enqueue_style( 'divi-child-style', CHILD_THEME_URL . 'style.css', array( $parent_style ) );

	$functions_script = 'divi-child-functions';

	$data = array();

	if( isset( $_GET['et_open_accordion'] ) ){
		$data['accordion'] = $_GET['et_open_accordion'];

	if( isset( $_GET['et_open_tab'] ) ){
		$data['tab'] = $_GET['et_open_tab'];

	wp_register_script( $functions_script, CHILD_THEME_URL . 'functions.js', array( 'jquery' ), '1.0', true );
	wp_localize_script( $functions_script, 'openers', $data );
	wp_enqueue_script( $functions_script );

add_action( 'wp_enqueue_scripts', 'divi_child_theme_enqueue_styles' );

Step 4: Putting it all together.

So, you have your functions.php file, retrieving the passed variables, setting up the javascript variables and enqueing the relevant javascript file to make it all work. All you have to do now is create a page with anchors that link to the correct location, including your query strings. And we’re all set.

To make it easier for you to test out, I’ve create a very basic Divi child theme, including all the above code, that you can just install, configure and use out of the box. You can grab this child theme demo from the GitHub page.

One thing to note, this article and child theme are for the purposes of explaining the basics of linking to open tabs or accordions. In the real world you should be considering escaping the query variables in the PHP to ensure no one injects any dodgy code into your site. This article is a good place to start.

Happy Divi-ing.

Update: Thanks to Nathan Duvall for pointing out how to manage this with Divi toggles.

        var et_hash = window.location.hash;
        if(window.location.hash) {
        $( '.et_pb_toggle' + et_hash ).removeClass('et_pb_toggle_close').addClass('et_pb_toggle_open');

Credit: https://bernadot.com/divi-theme-how-to-open-toggled-modules-with-a-url-hashtag/

Turn any button into an add to cart button

Turn any button into an Add to Cart button

The thing I love about blogging about WordPress is how many great questions come out of the comments of previous blogs.

Today, on my post on ‘Adding the cart button to your shop pages in Divi‘, I was asked the following:

I am trying to put an Add-to-cart button in the main Divi slider. Now Divi slider only gives an option to input a URL for the default slider button. But i was wondering is there a way to modify that button and convert it into a WooCommerce AddtoCart button?

So, there’s no way to make a slider button (or any other button for that matter) an add to cart button. But what you can do is replicate the Add to Cart functionality on any button by entering the right url.

What a lot of people don’t know is that all the Divi add to cart buttons are doing is performing the add to cart action behind the scenes. To add a product to your cart all you need to do is pass a a variable called ‘add-to-cart’ with a value that is the id of a product and WooCommerce will add that product to your cart.

So lets say your site url is http://www.myawesomeshop.com/. To turn that url into an add to cart url you just need to add ?add-to-cart=[ID] to the end of it, where [ID] is the id of the product you want the customer to add to their cart.


If you aren’t sure what the product id is, just look at any product. It’s the value that appears next to ID when you hover over a product. If you edit a product, its the value for post that appears in the address bar


Also, make sure you include the trailing slash at the end of the site url, otherwise things won’t work.

So that’s it, append ?add-to-cart=[ID] to the end of your site url ( don’t forget the trailing slash ) and turn any url into an ‘add to cart’ url.

Happy Diviing.


Going out with a bang!

We’re already halfway into the month of October, so this post is a little later than planned. I’ve just got back from a short break with my family and I’m recharged and ready to create new blog posts and plugins (or complete existing ones) until the end of the year. I thought it might be fun to post a little about what I have in store for what’s left of 2016.

Elegant Forms

I haven’t touched Elegant Forms since I blogged about it but I am recommitted to completing and releasing the plugin before 2016 ends. The one area that Divi is sorely lacking in is a better form module so I hope to bring this to the community as soon as possible.

Admin Title

On of the great ideas that came out of the Divi Theme Users group was a plugin that automatically updates the admin title of a module based on a specific field in the module itself. I coded up a proof of concept on the night of the discussion but it pretty much stayed there, so I want to revisit and release this little plugin as soon as possible, specifically for all the site builders out there.

New Directions

I want to start moving into Divi Layout and Child Theme creation. As I am not a designer I have to rely on the work of others to help fuel this, so today Atlantic Wave released a bunch of Elegant Themes inspired layouts for Divi. I have a few child themes I am working on that I also plan to release in the very near future, also inspired by the Elegant Themes demo designs, but with a little Atlantic Wave development twist.


As always, I constantly on the lookout for new ideas and new areas of development. If you have a plugin or theme development idea you would like to work on, feel free to get in touch.

WordCamp Cape Town – Day 1

So day one of Word Camp Cape Town is over. It was quite a whirlwind of a day, but I thoroughly enjoyed every moment of it.

My WordCamp experience actually started on Wednesday night, at the VIP dinner. Here I got to meet and chat with a bunch of folk from the local WordPress community who I had only ever ‘met’ online. It’s quite a thing to already have a relationship with someone and then only meet them in person for the first time (I wonder if this is how new Automattic employees feel at their first company meetup?) The vibe was great and I had some amazing discussions with some awesome people.

Today kicked off (after the obligatory 1 hour 20 minute drive from the outskirts of town) with my ‘Extending WordPress’ workshop. It went pretty well, there are some things I could have done better and some things that I nailed, but all in all I had good feedback. It’s always great hearing that people finally understood a specific concept because of your talk and one or two people mentioned that to me, which was amazing.

After that I sat in on Seagyn’s advanced talk on Continuous Integration, Unit Testing and Integration testing. I got to play with Travis-CI and I am excited to start implementing this knowledge into my development work flow

After lunch I decided to stay on the advanced developer track and thoroughly enjoyed Konstantin Obenland’s Settings API workshop. Being able to watch an expert at work is an amazing thing, and Konstantin ‘live coded’ his Settings API example with only one bug (which he fixed in record time) causing him a few moments of quiet contemplation. And I do really mean moments, in the time that it would have taken me to figure out the problem, he’d already figured out the problem and the solution. Amazing stuff.

The day ended with a really fun and interesting talk from Steve and Danielle. I really enjoyed the way that made the entire workshop interactive and interesting. I would have easily listened to a workshop on how to increase your site speed, but they presented it in such a way that they actually made me excited to just go and learn how to do it myself. Well done guys.

Other things that stood our where how many of the local Divi community were present, where ever we ran into each other the obvious topic of conversation was Divi 3.0. I even had the chance to speak to some non Divi users and discuss the theme and its merits with them. I am definitely looking forward to meeting all the Divi Users that are at WordCamp tomorrow at our unofficial Divi Meetup.

All in all day one was pretty special. What inspired me the most was  how full the three different tracks were, I’m looking forward to seeing and interacting with everyone in the single regular sessions track tomorrow


Adding the cart button to your Divi shop pages.

As is always the case with these code snippets, this one comes from a question by a user in the Divi Theme Users group on Facebook.

Leif Ottosson asked about the ‘Add to Cart’ button on the Divi/WooCommerce shop page. When adding the Divi Shop Module to a page via the Page Builder, the list of products on that page does not include an ‘Add to Cart’ button. The idea being that the user should first view the product before adding it to their cart.

Sometimes, however, it may be quicker or better (from a UX  perspective) to allow your user to add to their cart, straight from the product list page.

This can be achieved by using the following PHP code snipped, either in the functions.php file of your child theme, or in a plugin.

// register add to cart action
function dac_add_cart_button () {
    add_action( 'woocommerce_after_shop_loop_item_title', 'woocommerce_template_loop_add_to_cart', 10 );
add_action( 'after_setup_theme', 'dac_add_cart_button' );

Replace the ‘dac’ prefix with any prefix of your own and you should now see the ‘Add to Cart’ button underneath the products on any page where you have used the Shop module.

Making child themes part of your business development best practice.

In part one of this series on child themes, I discussed the hows and whys of child themes. Hopefully you understand what they are and why you should use them. In part two I want to discuss the various ways you can access or create child themes as well as show you some cool things you can do with a child theme.

A quick note to the reader, this article is aimed at Divi designers and developers. If you don’t use Divi most of this article will still be relevant, but some of it will be very Divi specific. Also, before we continue, I would like to point out that I wrote a supplementary article to part one discussing the basics of a WordPress theme. If you don’t know how a WordPress theme works I recommend you read that article first before continuing with this one.

Everybody caught up? Right, let’s crack on then shall we…

There are three ways you can get a child theme, buy one off the shelf (from any of the Divi related marketplaces), roll your own using a number of child theme makers available, or create one yourself from scratch (DIY). Lets look at all three options.

Off the shelf

Off the shelf child themes are great. You get a pre built child theme customised with the developer’s choice of style and functionality included. What is quite unique about most Divi child themes is that you also get demo content included with the theme. The ease at which child theme developers can create demo content using the Divi builder and the recently upgraded portability system means you literally get a fully functioning website out of the box. All you need to do is update the content, replace images and tweak some styles here and there and your site is ready to fly. If you want to get a website up and running quickly, these off the shelf child themes are just what you need.

Roll your own

What I like to call a ‘roll your own’ child theme is one that you create using one of the online child theme creators. There are a few options available out there, just Google ‘divi child theme’. These are a pretty cool intermediary step. What the child theme creator does is ask you to input a few fields and it will generate a child theme archive for you to download. This child theme has the most basic of functionality (mostly just rewriting the Elegant Themes footer credits) but it is a great way to see the basic inner workings of a child theme and learn to build your own from there.

Do it yourself.

Otherwise known as ‘developing a child theme’. This is how the pros do it. Don’t get me wrong I have nothing against either off the shelf or roll your own child themes, but if you really want to understand not only child themes but WordPress themes and/or theme development, then you should really be developing your own. Not only does it give you a skill that is sought after, but it will open up a whole new avenue of WordPress and Divi customisation, giving you endless scope to create unique websites for your clients.

Now, as this series of articles is focusing on how to do it yourself, lets learn how to create a child theme.

The very basics.

All of what I am describing here you can read about in the WordPress documentation on child themes. In short, a child theme simply inherits the layout, styling and functionality of the parent theme but gives you the ability to override any of this layout, styling or functionality. A child theme only needs two things to be considered a child theme:

  • a directory (or folder) to contain the child theme files
  • a style.css file

The name of the directory is irrelevant. WordPress recommends naming it after the parent theme (eg ‘Divi-child’) but this is not required. Mostly developers prefer to name it after the site its being used on or give it a descriptive name based on it’s content. It honestly doesn’t matter. What does matter is what is inside your style.css file.

The header of the style.css contains the most important part of the child theme, the parent theme registration. This is placed inside CSS comments at the top of the style.css file.

 Theme Name:   Divi Child
 Theme URI:    http://example.com/divi-child/
 Description:  Divi Child Theme
 Author:       John Doe
 Author URI:   http://example.com
 Template:     Divi
 Version:      1.0.0
 License:      GNU General Public License v2 or later
 License URI:  http://www.gnu.org/licenses/gpl-2.0.html
 Tags:         light, dark, two-columns, right-sidebar, responsive-layout, accessibility-ready
 Text Domain:  divi-child

Now the only really important part of this is the Template field. To ensure that this is registered as a Divi child theme you need to set Template to Divi. The rest of the fields are not important for a child theme to function, but it’s a good idea to at least give your theme a Theme Name and Version. If you are developing themes for client sites or to sell, its also useful to include the Author URI, as a link back to your site. Finally, while it is not a requirement to do so for the theme to work, because your child theme extends WordPress, which is licensed under the GPL, you should also include the License and License URI, as your child theme will also fall under the GPL.

You can literally start copying template files from your parent them (in this case Divi) to your child theme and edit them to achieve the effect you require. Some of the common things you can do is:

  1. Copy the footer.php file to edit the footer credits (probably the question that is asked the most by new Divi builders)
  2. Copy the archive.php file to change how the default blog archive is displayed.
  3. Copy the /includes/social_icons.php file to add additional social media icons to your header or footer.
  4. Copy the 404.php to create a custom 404 page for your site.

Quite honestly the sky’s the limit. Any file that is ‘auto included’ in the Divi theme can be overridden by copying it to your child theme and making the changes you require. You can also use the Template Hierarchy to create other files in your child theme to change how Divi renders certain views, for example creating a category.php file to enable how your category pages are rendered.

Working with style.

So obviously seeing as you have a style.css in your child theme, you’re going to want to also use it to add custom CSS to the site you are working on. As mentioned in part one, this is a quicker way to add custom CSS to your child theme and in my opinion easier to manage and tweak. For this to happen you’re going to need to add a functions.php file to your child theme. By adding this file you can queue up the parent and child style sheets, as well as use it to add any custom PHP functionality to your child theme, and therefore your site.

A good methodology is to simply always create a functions.php in your child theme with the following PHP.

function my_theme_enqueue_styles() {
    $parent_style = 'divi-style'; // This is the 'parent-style'.
    wp_enqueue_style( $parent_style, get_template_directory_uri() . '/style.css' );
    wp_enqueue_style( 'divi-child-style', get_stylesheet_directory_uri() . '/style.css', array( $parent_style ) );
add_action( 'wp_enqueue_scripts', 'my_theme_enqueue_styles' );

What this does is the following

  1. Registers a function called ‘my_theme_enqueue_styles’, to be fired when the WordPress ‘wp_enqueue_scripts’ action is fired.
  2. Enqueues the parent theme style sheet (in this case the style.css from the Divi theme)
  3. Enqueues the child theme style sheet (in this case the style.css from your child theme) and makes it dependant on the parent style

It’s important to note that the parent theme style needs to be loaded as well as the child theme style, and in which order, so that the child theme styles override the parent theme styles, should they be applied to the same HTML elements.

Once that is done you can do ahead and start adding custom CSS to your child theme style.css. As I’ve said before this is the recommended way to make large CSS changes to your Divi site.

Fully functioning.

But what else can be done with the functions.php file? Well this file really acts like a plugin file for your child theme. So you can add pretty much any custom functionality to your child theme in this file. Some examples include:

  1. Creating a function that will allow you to edit the contents of your footer credits from the WordPress Customizer
  2. Pre populating your new Divi site with common Divi settings
  3. Adding custom widgets
  4. Adding custom functionality to your Divi site, like custom modules or layouts.
  5. Customising the WP admin area

The sky is the limit really.

Active stations

Once you have created your child theme you will need to install it within WordPress. This is done by uploading an archive (zip) of the child theme directory via the Appearance -> Themes menu in your WP admin area (just like you would any other theme) and activating it.

A simple example.

I thought I would round of this article with a simple example of (more or less) all the things I’ve discussed above. I’ve created a simple child theme that registers two additional customiser settings for editing the Divi Footer credits. It also contains some custom CSS for the footer, just to show how custom CSS is implemented. You can download it from the GitHub repository.

For the next article in this series I will dive into each of the functions of the example child theme as well as add some more cool Divi specific things that can be done. I’ll also look at some of the comment WordPress specific things you need to know about, like actions hooks and filters.



Please, copy my ideas!

An open letter to all Divi plugin developers:

Please, copy my ideas!

I am, first and foremost, an open source developer. That means I believe that if you have a piece of software, either purchased or obtained freely via open source repositories, you should be allowed to ‘study, change, and distribute the software to anyone and for any purpose‘ (definition of open source software from Wikipedia). Secondary to that, I am a problem solver. I get great satisfaction when I can solve someone’s problem, specifically if it is with a piece of software I develop.

With that in mind, if I develop a plugin for Divi and you are developing/planning to develop a plugin for Divi that does the same thing or think you can do it better, please don’t stop. Build it, ship it, make it happen.

One of two things will occur.

  1. Your plugin will be superior to mine
  2. Your plugin will be just a copy of mine, with little to no added benefit.

Let’s consider both options

If your plugin is superior to mine, I will (silently, or maybe even publicly) congratulate you. If we ever end up discussing it, I’ll probably even share my original source code with you, if it helps you improve yours. In fact I’ve done this before with the developer of the Image Intense plugin. Image Intense does so much more than my little Image Overlay plugin every will. When I recently ended up in a discussion with the developer (over a totally separate post I shared and he found use for), he mentioned his soon to be released plugin with me. I shared my source code with him on the spot, should he ever find any use for it. Don’t believe me? Ask him yourself.

If your plugin is just a copy of mine, I’ll simply shrug it off and move on with my life. I’m actively working on new plugin ideas every week (literally, I was working on one this week and another plugin idea came to me, via a conversation with a previous client, which I started on the prototype for) so if you make something that copies anything I do, I’ll take it as a compliment. After all, they do say that “Imitation is the sincerest form of flattery.”

There are some things that I do find reprehensible.

I personally feel that if you are a developer/designer/site builder and you are using a piece of software for a client project that requires payment to obtain, you should at least pay for that plugin. I’ve seen sites where premium plugins and themes are listed free to download, citing the GPL is the legal reason why they can do this. Legally they are not wrong, nor ethically, as the GPL allows for this (see my definition of open source above). But I do feel that if you are selling your services as an expert, but part of your expertise is using a specific plugin to achieve a desired result, you should at least buy that plugin for your arsenal of tools. Having said that, because it’s GPL, there’s not really much anyone can do about it. You’re allowed to, so if you have no issues with doing it, then so be it.

I also do not agree with the concept of just copying and re-branding someone else’s code as your own. So if you buy any of my plugins, or obtain a copy of them via some other means, copy all the code verbatim but give it a new name to sell on your website (and I find out) I will call you on it. However, again because it’s GPL, there’s not really much I can (or will) do about it.

Competition is a healthy, natural part of being in business. As far as I am concerned, competition breads innovation. So please, compete with me, show me what you can do and I’ll show you what I can do. If you can do it better than me, great. My motto is not to be better than anyone else, but just to be better than the person I was yesterday.

At the end of the day the people who really win are our customers. And isn’t that the reason we got into building products in the first place, to solve our customers problems?


The Basics of a WordPress Theme

In the first part of my article on child themes I explained a little about the history of WordPress themes and child themes, what they are and why you should use them. After sharing the post in a couple of online groups I am a part of, I received a fairly good positive response to the topic and my thoughts on it. One thing that also stood out from some of the comments was that a lot of Divi users don’t necessarily know how a WordPress theme works in the first place.

Everything I am writing about is (pretty much) included in the WordPress Theme Handbook, specifically the articles on the Template Files, Template Hierarchy and Child Themes. If you can afford the time to read through the handbook I highly recommend it. However it can sometimes be a little technical, so it’s often easier to get a ‘primer’ on the topic, to give you the relevant information you need in a manageable size. So, based on the responses to my first article I’ve chosen to first write this article to explain a little about how WordPress themes work.

Understanding the basics

To be able to understand child themes, first we need to understand WordPress themes. This means we need to talk a little about the Template Files and the Template Hierarchy. I’m not going to go into too much detail, but in short it’s the way in which WordPress looks for and loads the various template files in your theme to render content.

Template Files

Any WordPress theme has a base set of template files that is uses to render content for different sections of your WordPress site. If you take a look at the files inside a ‘standard’ WordPress themes (like those found on WordPress.org) you will see that, at their base level, all themes are made up of of two things, a style sheet and a bunch of php files, also known as templates. Theses templates include, but are not limited to, files like the header.php, footer.php, archive.php, single.php page.php and sidebar.php. Each of these templates performs a different type of task within your WordPress theme. The templates themselves are also divided into different template types, depending on what they do.

Template partials are template files that will be included inside another template file. For example the header and footer template files are partials. They will be included (and reused) inside other template files to render specific sections of a page, in this case the header and the footer of the site.


  • header.php – contains all code to render the header
  • footer.php – contains all code to render the footer
  • sidebar.php – contains all code to render the sidebar

The common WordPress template files are the templates that will render the specific content of your site they related to. They can be very specific (rendering a specific category of posts, or a specific page) or very generic (for example the index.php file which will be used whenever a specific template file doesnt exist for the content being rendered)


  • page.php – contains the code to render a page
  • archive.php – contains the code to render any blog post archive (or list)
  • single.php – contains the code to render any individual post

If you read up in the Template Files section of the theme developer handbook you can learn what each one does.

Template Hierarchy.

The next thing to understand is the template hierarchy. This is the way in which WordPress will look for a series of template files to render the specific piece of content. If the first template in the list doesn’t exist it will keep going down the list until it finds a template it can use. The easiest way to explain this is to take a look at a WordPress blog.

On a standard WordPress blog, you usually have a ‘list view’ (list of blog items, a thumbnail image, an excerpt and some form of link to the full article) and then an ‘article view’ (the actual article itself, including any content for that article). So, that means that you would need at least two templates, one to render the list view and one to render the article view. This means that the WordPress engine will look for a template for each view and use it to render the content. For the list view, WordPress will look for a ‘archive.php’ file in your template folder to render the list view and a ‘single.php’ file in your template folder for the article view.
So your archive.php would contain some HTML to display the list view as well as a WordPress Loop to render the list of blog posts, and the single.php would contain HTML specific to the article view, as well as some PHP to get the relevant article content for display.

Now, if you are a theme developer you are probably swearing at me right now, and that’s fine. That last statement is not 100% correct but I am simplifying it a bit, bear with me.

So great, there is a template for list views and a template for article views, what now? Well, lets say that you want to have links to a list of blog posts per category and you want a different display for each category list view. Whenever a user views blogs under a certain category you want to include a description of that category above the list view. Well you could do this in two ways. Either you would add some code to your archive.php to check if the user is browsing a list of blog posts per category and show that description or you can use the category specific templates in the template hierarchy and create a different template per category. For example, if you had a category with the slug ‘products’ and you created a template in your theme called category-products.php, whenever the user browses to the products blog category, WordPress would use that template file to render the products category blog items. This is useful because it means you don’t have to add extra processing to your archive.php template file and you can just service products category specific content to the user, just by adding a template file.

The other important thing to understand is that for each level of WordPress, from pages to posts, categories to tags, there is a hierarchy in place as to what gets loaded. So for example, when WordPress renders a list of blog posts, it first looks for a category specific template (either by slug or by id) then a general category template, then the archive template and then finally the index template. So in our products category example above (lets say the product category id was 5) WordPress would look for the following template files, in this order, to use to render the list:

  • category-products.php
  • category-5.php
  • category.php
  • archive.php
  • index.php

That’s 6 levels of template hierarchy that you could use to render things differently for different points of just your blog!

The same goes for blog posts, you have the following set of templates at your disposal when developing a theme. Lets say I was rendering a page with the slug (or name) ‘my-page’ which has an id of 7. WordPress would look for the following templates, in this order, to render the page content:

  • a custom template file – (The page template assigned to the page in WP admin).
  • page-my-page.php
  • page-7.php
  • page.php
  • singular.php
  • index.php

Each template is the fallback to the previous template, with index.php being the final template for pretty much all sections of a WordPress site. You can probably see now why any theme developers reading this article were a little annoyed at my oversimplification of the theme hierarchy earlier ;-).

To get a better understanding of the different levels of template types available to you, as well the order in which WordPress loads them, I highly suggest you read Hierarchy in Detail section of the Theme developers handbook.

So what does this mean in terms of Divi. Well the base of the Divi theme is a small subset of the template partials and common template files. Divi doesnt have (for example) category based templates or even an archive template in its template file list. Because Divi has modules which render the blog lists and pages. Divi tends to use the templates towards the end of the hierarchy (single.php page.php and index.php) to render all content, because the modules are handling all the grunt work. However we need to have an understanding of what these template files do and how they can be ‘overridden’ using the hierarchy to be able to build our child theme.

A peek inside the Atlantic Wave workshop

It’s not every day that I get really excited about a plugin I am working on. Don’t get me wrong, every plugin I develop is exciting, but more so from a ‘solving a puzzle’ or ‘fulfilling someone else’s requirement’ point of view. Granted, this is the reason I got into plugin development and it is a great feeling to know that people out there are using my plugins to make their lives easier.

What I’m talking about is the excitement I get about the fact that I am busy developing a plugin that not only will make others lives easier but also the fact that I it has scope to become so much more than the current sum of its parts. It’s one of the first plugins I’ve written that has the potential for so much more than what I am aware of and I am more excited about the future feature requests I’m going to get from the Divi community than anything else.

Allow me to introduce you then, to Atlantic Wave’s Elegant Forms plugin.

Building on the base of the Divi theme Contact Form module, with Elegant Forms I hope to fill a gap that, up to now, has required to the installation of other third party plugins like Gravity Forms or Contact Form 7. By baking Elegant Forms right into the Divi Page Builder I hope to bring the same extended functionality to your Divi site builder experience.

I’m about halfway through development of version 1 and I’m already planning the features to be added to future versions. I’ve included some ‘sneak peek’ screenshots of some of the functionality below. If this excites you as much as it does me, comment below and let me know what you think. I’d also love to hear your requests for features to be added to this plugin.

As an added bonus, if you comment with your thoughts or a feature request below, when the plugin releases I’ll randomly select a winner from the comments to receive a 100% discount coupon on Elegant Marketplace, effectively giving you a free copy of the plugin at launch.