What’s your Git Strategy?

As a freelance WordPress developer/consultant I rarely work in a team environment. So my usage of Git is mostly for my own purposes of being able to have my code backed up somewhere and the ability to create branches to try out new pieces of functionality without affecting the ‘master’ code base.

Recently I was chatting to Simon Dowdles, another Cape Town based WordPress developer, about this. He is, in his own words, very strict about a Git workflow. We agreed that it would be a good idea to implement a better system, so we put his workflow into place.

  1. Development branch is where all UP TO DATE and approved code lives
  2. Master branch is the truth and is ALWAYS what is on production
  3. Feature/hotfix branches are branched off of develop and only come back into develop with a Pull Request
  4. Release branches are made off of develop for releases, the release is done, merged back into master and tagged with the appropriate version tag (ie 1.2.0)
  5. Release branch is deleted, and there is only ever one

On the surface this all seems very obvious but it is often something that one tends to dismiss when working alone on the code base. After working with it for a few days however I can already see the benefits.

Lets first look at a real work example of how this would work in practice.

Setup

Firstly the repository is going to need a develop branch. So inside the root of my project folder I’ll create the develop branch from the master branch.

git checkout -b develop

And then push the branch

git push -u origin develop

If the develop branch already exists I can just switch to it

git checkout develop

Now I will need to create my feature branch, to make my code changes. So while still on the develop branch, create a a feature branch

git checkout -b feature/my-cool-feature

Usage

I can now starting coding my changes, committing frequently. I tend to commit every time I complete a chunk of functionality. So if I fix a bug, I commit. If I add a function and its more or less complete I commit.

git commit -a

At the end of every day, or if I am going to leave my workstation for a period of time, I push all current commits to the feature branch.

git push -u origin feature/my-cool-feature

When I am convinced it is good to go, I will submit a pull request or PR. When I create my PR I will request that it is merged into the develop branch, NOT master.

As we are using GitHub for this project I prefer to use the web based tools to create a PR, but most of the other cloud based Git services provide similar tools.

The rest of the team will review this PR, which will involve testing. They will scrutinise my code and provide feedback and I will fix or alter things to suit the team/project coding style(s).

Each time I commit the above changes, the team in the PR is notified and will see the changes in the PR.

When everyone is happy, they approve the PR and I merge my PR into the develop branch. At the same time I can choose to delete my feature branch (which I typically do)

The develop branch now has more (stable) code in it, and part of my PR should have been a version bump. (for example let’s say to 1.0.1)

Release

The team decides it is time to release version 1.0.1

First I need to make sure all my code is up to date

git pull

And then make sure I am in the develop branch. This is the branch that has all the approved code for the next release (1.0.1).

git checkout develop

I create a release branch called release/1.0.1 off of develop

git checkout -b release/1.0.1

The code gets deployed ( in this case its a WordPress plugin, so it means pushing all the code to the wordpress.org plugin repository, more on that another day 😉 )

 

I then merge the release/1.0.1 branch back into the master branch and tag it as release 1.0.1, again using all the GitHub PR, merging and tagging tools.

And we’re done, release 1.0.1 is in the wild and by following this approach, master is ALWAYS the truth. If for example release 1.0.2 were to fail, we simply roll everything back to master.

Wrap up

I’ve been working like this for three releases of the project so far and I have to say, once I had all the steps in my head, it did make developing, merging and releasing a lot smoother and more controlled.

Are you using Git as part of a team? If so I’d love to hear your comments on the idea of having a Git Workflow/Strategy.

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

<script>
jQuery(function ($) {
    $( document ).ready(function() {
        $(".et_pb_button").on("click", function(){
            event.preventDefault();
            alert("Button clicked"); 
        });
    }); 
});
</script>

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:

 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' =&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.

(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/

Horizon

Remembering Why – Part 2

Some time ago I wrote a blog post on remembering why I got into developing web applications in the first place. At the time I was struggling to find my focus as a developer. I’m happy to report that since then I have (more or less) figured that out.

I’ve since realised that one of my problems is that when I started out, I didn’t have a vision, mission statement or personal creed for why I wanted to do what I am doing. I just knew that I wanted to do it. Being on my own I didn’t think of such things, I tend to just rush in where angels fear to tread and then figure it out as I go along.

Today I was introduced to the Automattic creed and I was blown out of my socks. It really resonated with me, as every point in the creed is something that I believe in, a reason why I became a web developer and why I support and believe in open source as more than just a decision on software licensing. So, going into 2017 I am going to remind myself of this as much as possible.

Here is the Automattic creed:

I will never stop learning. I won’t just work on things that are assigned to me. I know there’s no such thing as a status quo. I will build our business sustainably through passionate and loyal customers. I will never pass up an opportunity to help out a colleague, and I’ll remember the days before I knew everything. I am more motivated by impact than money, and I know that Open Source is one of the most powerful ideas of our generation. I will communicate as much as possible, because it’s the oxygen of a distributed company. I am in a marathon, not a sprint, and no matter how far away the goal is, the only way to get there is by putting one foot in front of another every day. Given time, there is no problem that’s insurmountable.

That’s pretty powerful stuff!

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.

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.

 

work-review

Codeable Review – October 2016

October marks my second month at Codeable. My first month was very quiet, mostly because I was still busy with other things in September, including WordCamp. I also took my time getting into the Codeable process, commenting on only a few smaller tasks. I closed my first small task mid October, so I’m considering October as my first official month as a Codeable developer.

It should be noted that due to my other commitments I only have an average of about 20 WordPress development hours available in a week, which I try to split between plugin development, blogging and Codeable work. This means I tend to focus on smaller projects that don’t require my time for longer than about 4 – 6 hours a day, unless the deadline is very flexible.

Fellow Codeable expert, WordCamp speaker and all around nice guy Nathan Ello believes “transparency trumps secrecy” and I tend to agree with him. With that in mind, below you will find my income and client reviews from Codeable for the month of October.

Show me the money

First, a quick calculation. Based on the minimum number of hours I have available for Codeable development (4) and the Codeable minimum suggested hourly rate of $60, I am aiming to earn about $720 per week or about $2800 per month. For some this may not be much, but for my situation it is an acceptable amount (for now). I am also basing my income for the month on the amount I can withdraw on the 25th of that month, so any project I get hired for during or after that day, or that gets paid out after that date, gets moved into the following month.

So how did October go? To be honest it wasnt amazing, but I am happy with it. I’m already on a good path to more than double my October income in November and I’ve more or less figured out a good balance between Codeable work and my other ventures.

My total Codeable income for October is $504.50. Now as you will agree that’s only about a quarter of my target amount above, but I really only closed those projects in the last week of October. I was also hired for a task of about $1000 in October that is still ongoing and I have another project of a little over $1000 lined up for November. So November is already close to my target within the first week.

Happiness report

More important than the money is how my clients view my work. As I don’t have a lot of closed tasks for October I don’t have a huge amount of reviews on my profile, but those that I do have are very positive.

“Jonathan is The Best! Very knowledgeable and Very Professional. He is the right man for all Tasks. Glad to find him here. :)”

“Perfect teamwork. Clear communication and perfect coding.”

“A star! Smashing tutor”

A few thanks

Getting through the first few months at Codeable wasn’t easy with my specific situation. I had a few ups and downs, and I probably wouldn’t have made it this far without the help of the Codeable support team (Chris, Raleigh, Liam, David and Per) and a few fellow developers (Justin, Robin, Panos and anyone else I’ve forgotten to mention, who make hanging out on the Codeable Slack a blast) who helped and guided me along the way. A special shout out to Justin who had a nice little chat with me on Slack one day and gave me the push I needed to get back up in the horse, thanks man!

October was OK, November is already looking good, here’s to wrapping up the year on a great footing to kick off 2017 with a bang at Codeable!

Taking the pain out of self managed cloud hosting with ServerPilot

(Disclaimer, links to ServerPilot and Digital Ocean contain referral codes, if you use them and make a purchase you’ll be putting a few extra $’s in my pocket)

As the web and it’s associated technologies move ever forward, the solutions available for hosting your website are about as abundant as the options available for creating it.

One of my favourite advances in hosting options has been the advent of Virtual Private Servers or VPS. What I like about VPS is that it gives you the same level of control to the base system as a physical server, but at a fraction of the cost, and with similar performance to a physical server. Over the years services like Amazon AWS, Digital Ocean and Linode have really reduced the cost of creating and managing your own web server using VPS technology. The only problem with using a VPS is that you need to have a level of understand of server technology, software and server administration to be able to setup and manage such a server, something which most web designers, developers and builders do not.

With this in mind I was quite pleasantly surprised when someone pointed out ServerPilot to me. ServerPilot provides a fast, managed and secure way to manage your VPS without needing too much technical knowledge. On installing ServerPilot on your newly purchased VPS, you are given tools which allow you to create and manage multiple PHP apps on your server. What is even better is that ServerPilot supports WordPress straight out of the box, so setting up a new blank WordPress site is a simple matter of clicking a few buttons.

Without a doubt one of the things I love about ServerPilot is the technology stack. It’s built using Nginx in front of Apache, comes pre installed with PHP-FPM and supports PHP 5.4, 5.5, 5.6, 7.0, and 7.1, all on the same server. It even installs and configures a firewall on your server as well as SecureFTP access, automatically updates itself and supports LetsEncrypt SSL, giving you the option to install and configure free SSL certificates for all your sites. Finally, depending on the package you choose, it provides various levels of server monitoring, from basic server CPU and Memory usage, all the way up to slow script reporting.

ServerPilot is about the best tool for web professionals who would like a little more control of their (and their client’s) hosting options. At $10 for the ‘Coach’ version, you can install and manage as many servers as you like. It’s designed to use Digital Ocean servers, but supports the majority of the VPS services out there (Amazon AWS, Rackspace, Linode, Microsoft Azure, Google Cloud).

If you are currently using VPS based services or are looking for alternatives to your current hosting provider, I highly recommend to try out the free version of ServerPilot. If you don’t want to spend any money on the VPS to try it out, you can use my Digital Ocean referral link for a $10 credit, which is enough for a 512MB droplet for two months, more than enough time to test out the service.

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.

<?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.

 

 

The definitive guide to calculating your billable rate

Recently on the WordPress South Africa Slack channel, a member asked the following question:

“Can we talk pricing? How do you figure out how much to charge for WordPress Development? What factors influence your pricing?”

A bunch of other freelancers (including myself) piped in and gave our opinions, but it was Nathan Jeffery’s post that really nailed it. (The figures below are quoted for South African currency/costs, but you can adjust it to your specific situation).

“Whether you charge a fixed rate or hourly the important thing to do is figure out your costs and from there work out your billable rate.

For example:

Monthly costs

  • Rent: 7,000.00
  • Adsl/Fibre/3G: 2,000.00
  • Electricity: 1,500.00
  • Food: 3,000.00
  • Hardware (50k depreciated over 3 years): ±1,400.00
  • Accounts and Auditing (10k per year split over 12 months): ±900.00

This makes your target income 15,800.00. Add a buffer of 20% for rainy day and savings, giving you 18,960.00 per month as a target

Potential billable hours

Next we need to determine how many hours can actually be worked in a month (on average).

If we assume you’re willing to work 10 hours per day and 6 days per week, that gives us 60 hours a week (240 hours per month) to work with.

Let’s assume that 60% of your time will be spent doing promotions, looking for opportunities, quoting, doing admin etc. This means you’ve only got 96 hours available in the month to work on paid work which is 4.8 hours of productive time per day, which is pretty reasonable.

Calculate your hourly rate

Based on these values we can work out an initial hourly rate.

Target (18,960.00) divided by potential billable hours (96) = 197.50 per hour, let’s round this up to 200.00.

This means if you’re booked 100% of your billable time, you could survive by charging 200.00 per hour.

The reality of the matter is that it’s unlikely you will be booked 100% of the time, at least not in the beginning, so you need to factor that into your survival costing.

Let’s assume you’ll be working 50% of the time which means you’ll need to charge twice as much per hour, therefore 400.00.

When working out your fixed cost quotes, you can/should use at least 400.00 per hour as your base rate to calculate what you should be charging.

You should also factor in time you need to allocate towards things like:

  • Having a holiday and paying for it (if that is your thing)
  • Learning and continued self development (the more you can do and the quicker you can do it, the more you can charge per hour)
  • Time off sick (it sucks but it is a reality so you need to budget for it)
  • Reserve for tax etc, if you’re invoicing in your own name you’ll be taxed as an individual and probably need to register for provisional tax. You need to make sure you keep enough money aside to pay your taxes when it’s required, don’t want to get in trouble with the taxman

This model can obviously be tweaked but should give you some idea as to what you’ll need to consider.”

Nathan was also kind enough to share a Generic Freelancer Costing Template that can be used to calculate your billable rate.

I can honestly say that is the best guide I’ve ever seen for calculating your billable rate. Instead of focusing on what your competitors are charging and merely going lower, are you billing according to your costs vs available work hours?

You can read about Nathan on his website or follow him on Twitter.