Categories
Divi

Why I’m not building any new Divi plugins, or adding features to any existing ones.

If you’re reading this because you found me through the various Divi Facebook communities, you probably know that I am/used to be a Divi plugin developer. You may have already purchased one of my plugins and found this link on the Atlantic Wave home page.

When I first started in the WordPress space I built a few custom plugins for the Divi theme and sold them on Elegant Marketplace, the most recent (and probably most popular) one being Rebrand DE.

Rebrand DE was launched in June 2016, over two years ago. Since then I’ve not released any new Divi plugins and I’ve only released one free plugin on WordPress.org, roughly at the end of 2016. I’ve also not added any new major features to any of my existing plugins. So why no new plugins, or plugin features, in almost two years?

1. Money

The first mistake I made when releasing my plugins was not pricing them properly. Take a look at Rebrand DE, it sells for $18 once off, which is great for the consumer, but a bad business model for me as a developer, trying to support the plugins. I probably ended up making about $250 a month from Divi plugin sales, but spent at least 5 times as much on support queries, which meant a net loss for me. 

However the income I was (or wasn’t) receiving from the plugins wasn’t the major problem, the major problem was…

2. Time

Building a plugin empire is a game for those who have a lot of free time on their hands. In the first month I made $1500 on plugin sales, but each month after my sales dropped, until they reached the average of $250 a month income I mentioned earlier. At the same time I was supporting customers who purchased the plugin, as well as trying to fix bugs and add new features to the plugins. So I struggled to find time to market the plugins to new customers, or look at how I could do things like increase the price or implement new features.

Essentially the time I spent on the plugins was cannibalising what I made out of them, as well as my main source of income, custom client work. I had to start making excuses for why I wasnt able to fix bugs as quickly or ship new features. As a husband and father it also meant I was spending more of my time on supporting the plugins and less with my family.

I soon came to a realisation.

Having enough time to fix bugs or ship new features meant I would have to increase the cost of the plugins to accommodate. Because I was not clever enough to launch the plugins with things like yearly license/support renewals this meant upping the price dramatically for any new customers but still supporting the existing customers on the old prices. For whatever reason, this didn’t feel right. It was not fair to ‘punish’ new customers for my mistakes.

So, where does that leave us?

Before WordCamp Europe 2018 I decided that it was time to make a decision about the future of the plugins. I had a chat with the owner of Elegant Marketplace and we agreed that they would take over the bulk of support requests and would only contact me if major bugs occurred that needed fixing. I would take a much smaller cut of the profits, leaving me more time to focus on other things. It also meant that the plugins would be ‘feature frozen’ and any new (or planned) features would not be added going forward. 

“I want feature x in one of your plugins”.

If you are reading this because you clicked on a link from the Atlantic Wave site and you want a specific feature in one of my plugins, then you do have the option of hiring me to build it for you. If you choose this route I’m open to a ‘profit sharing’ option, if you’re willing to let me upgrade the plugin for the public domain (ie to be sold with the new feature on Elegant Marketplace) I’ll build the feature at a 50% discount on my development time.

Basically what it boils  down to is helping to cover the cost of my development time, should any new features be requested to be added to any of the plugins. That way you benefit, as you get the feature you want for half of what it would cost you actually build it, and I benefit from the profit share I make on the plugin sales over time.

I will still fix bugs.

I’m still committed to keeping the plugins up to date, so if you find a bug in any of my Divi plugins, please do email me, let me know and I’ll fix it as soon as possible. 

UPDATE (17/10/2019)

I’ve had reports that a few of the plugins are breaking on newer versions of Divi. This is because the Divi theme has undergone some major breaking changes, that affect third party plugins. If your plugin has stopped working due to these updates, I’m afraid I cannot fix this for free, as it will probably require a major plugin rewrite. If you would like to get the plugin updated, you’re welcome to hire me to do so. I am also open to the ‘profit sharing’ discussed above.

Categories
Development Divi Experiences Laravel WordPress

New focus in 2019.

Usually, towards the end of a year, I start looking back at the year that has been, and looking forward to the year ahead, planning my new goals and resolutions.

This year, however, I have one very specific goal in my head. It’s an idea that actually birthed itself way back in July of 2016, when I wrote a post about why I got into development and blogging about development, in the first place. 

2018 has been a year of personal goal achievement and so for 2019 I want to get back to sharing my (limited) knowledge and experience with others, to assist them in achieving their goals, both personally and professionally. So with that in mind I’d like to announce a few changes that will happen on this blog and my podcast, and a few other additions I’m making that will hopefully help support my efforts.

The Jonathan Bossenger Patreon

I have retooled and relaunched my Patreon page. The goal of this page is to give those of you who read my blog, listen to my podcast, or generally follow me online, the ability to help fund my work. I get a lot of folks asking questions in the comments area of my blog posts, and I’d like to be able to spend more time in helping them solve the problems they present. The Patreon is the perfect place to do this.

If you’d like to be able to get a little more out of me, from answering your questions to helping you solve your WordPress or web development problems, or you want me to write about specific experiences or topics, or even interview specific people on the podcast, the Patreon is the perfect way to have your voice heard. For a small monthly fee you can help me bring you the kind of content you are looking for.

The Jonathan Bossenger Mailing List

At the bottom of every blog post there is a ‘subscribe to my mailing list’ form. If I’m honest I’ve not really used my mailing list to it’s full effect. I intend to do so moving forward. I promise I won’t bombard you with rubbish, but I will select a few useful topics or articles, from either my blog or the web, that I think you will find useful, to send to you, no more than twice a month. 

I will also use this mailing lists to announce any new exciting things I am doing.

A new focus for the blog.

You may have noticed that I have been blogging a lot more the past few months. This is because I’ve recently started working with a copywriter, who is helping me get my content out there. While I will still use this blog to share my personal experiences, it is my hope that with the assistance of the copywriter I will produce more useful and relevant content to my readers.

WP HackerCast – Season 2

If you were a regular listener to the podcast, you will have noticed things went very quiet after episode 18. This was mostly due to not really having enough time to find guests and prepare podcasts. For 2019, and with the help of my Patreon, I hope to relaunch the podcast with more interesting guests and interviews.

So, if you like the sound of all this, and you want to be more involved in what’s happening here or on my podcast, then please consider becoming a Patron, subscribe to my newsletter, or visit and subscribe to the podcast.

Categories
Development Divi WordPress

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(){
    event.preventDefault();
    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(){
            event.preventDefault();
            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 ‘one’.

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

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

Happy Diviing.

Categories
Development Divi WordPress

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:

 http://mycooldomain.com/?post_name=my-cool-article 

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

 ?et_open_accordion=et_pb_accordion_item_1 

or

 ?et_open_tab=et_pb_tab_1 

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 ($) {
  //accordion
  $('#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);
  });
  //tab
  $('#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';
      $(accordion_element).click();
      $("html, body").animate({ scrollTop: $('#my-accordian').offset().top }, 1000);
    }
    // tab
    if (typeof openers.tab !== 'undefined') {
      var tab_element = '#my-tabs .' + openers.tab + ' a';
      $(tab_element).click();
      $("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' => '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.

(function($){
    $(window).load(function(){
        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');
    }
});
})(jQuery)

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

Categories
Development Divi WordPress

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.

http://www.myawesomeshop.com/?add-to-cart=[ID]

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

http://www.myawesomeshop.com/wp-admin/post.php?post=[ID]&action=edit

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.

 

Categories
Divi WordPress

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.

Development

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.

Categories
Divi Experiences WordPress

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

 

Categories
Development Divi WordPress

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.

Categories
Development Divi WordPress

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.

It’s also important to note that when loading the parent theme’s style.css in your child theme functions.php, you should always use the correct style handle (or name). For Divi this is ‘divi-style’. If you use something like ‘parent-style’, as shown in the example on WordPress.org, it will end up loading the child theme style sheet twice. The example on the WordPress.org codex is just that, an example. You shouldn’t copy paste that code without altering the parent handle to match the actual handle being used by the parent theme.  An easy way to check this is to enable the parent theme, view the source of the home page, and see what the id is of the parent style sheet being loaded.

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.

Categories
Divi Freelancing WordPress

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?