Gutenberg day 4 – New things

New_Office_Space
Today was a my first day in my new office space. Since becoming fully self employed at the beginning of 2016 I've been working mostly from home on a day to day basis. This has led to a few frustrating moments, although based on what I've seen I'm pretty sure I'm not alone in this.
In order to try and find better focus on my work and more of a separation of work and home life, I'm sharing an office space about 10 minutes from where I stay. It works out pretty well, except for a minor hiccup today which meant I lost about an hour of my day. The upside however is that I am less inclined to take my laptop out when I get home and I'm therefore less inclined to work after hours. Part of me still feels like I haven't done enough today but I'm hopeful that as I get used to the new setup I'll become more productive with the time that I do have for work. 
Filed under: Experiences, Freelancing

Gutenberg day 3 – Blogging every day is hard!

Blogging
Who knew? I often come up with ideas and jump into them without thinking. This has been both a blessing and curse over the past 40 years of my life. This idea to blog every day for September using Gutenberg was probably just as mad, as by the time I get to the end of the day I tend to forget to blog. So now it's 23:30 and I'm trying to get my obligatory post in before I got to bed. Perhaps I need to have a plan for this? In any case, this little personal discovery has led me to today's blog post, so at least I've managed to fulfill my quota.
Filed under: Experiences

Gutenberg – Day 2

This is probably going to be the shortest post I've ever written. I have nothing to say but I promised I would write a blog post per day for September using Gutenberg. This is that post for today.
Three's company
So here is a photo of myself, my wife Pamela and my son Ethan from about 3 years ago, this was (as far as I remember) the day we found out Luke was on his way. How much has changed since then…
Filed under: Experiences

A month with Gutenberg

Gutenberg
If you are in any way involved with WordPress and unless you've been living under a rock you're aware of the new Gutenberg editor that is currently in development. Gutenberg is what Matt and many other WordPress developers see as the future of WordPress. However, as with most new things, it's not been met with universal praise, with some even going so far as to review poorly, strange given that it is very clearly marked as a 'beta' product. Something that Matt and others have asked for is for user feedback. I've mostly stayed away from testing Gutenberg as I don't often have a lot of time for blogging lately. However, seeing as September is spring month in South Africa I've decided to try a little experiment. From today and for the rest of September I will attempt to write one blog post a day using Gutenberg. I am hoping that this will a) give me some time to test out the new editor and b) force me to write something every day. My ultimate goal is to try and both give useful feedback back to the Gutenberg team as well as start a pattern of blogging daily. Are you currently using Gutenberg? Let me know in the comments what your opinion of it is, by the end of the month I should be able to have worked with it enough to have formed my own.
Filed under: Development, Experiences, WordPressTagged with:

2017 WordPress resolutions – mid year check in.

Late last year I wrote down my 2017 WordPress resolutions. These were the goals I set myself (for better or worse) that I would like to achieve this year.

As we’re just over halfway through the year I thought it might be interesting to take a look back and see if I’ve made any headway on any of these items and whether I need to make some drastic changes for the next six months.

A more stable work environment.

If I think about it I have not yet quite achieved the ratio I had set out to, but there is some good news. I can’t remember when last I worked past 23:00 and I’ve even had some weeks where I didn’t have to catch up in the evenings at all. I have not yet been able to carve out time for plugin development though, so that is something I want to work on more. I can still be doing better with my project estimation so I’m constantly evolving that process.

5 for the future.

To be honest this has worked out, but in ways that I never could have imagined. Due to an unexpected set of circumstances I am the lead organiser for WordCamp Cape Town this year. I am enjoying this tremendously as I am really looking forward to putting together an even that could change someone else’s life as it did mine in 2015. I also recently joined the WordPress community team as a Community Deputy, meaning that currently I assist with vetting new WordPress meetup groups as well as hold Meetup orientations.

I still want to start contributing to WordPress Core as well as Calypso, the WordPress.com product, so I am looking forward to the the newly announced New Contributors meeting. I’ve also started learning React in order to look at contributing to Calypso.

REST API powered plugin

This one is still coming, as I’ve decided to build it using React for the admin sections (similar to Jetpack) so I need to finish my React fundamentals course first.

Twenty Seventeen theme

Sadly this won’t be happening this year, but I am getting a lot of experience using Twenty Seventeen on the WordCamp Cape Town site, so perhaps that counts?

WPHackerCast

This will also not be happening, however another podcast idea has revealed itself which is a much more exciting idea and one that will benefit way more people, so watch this space.

So, not to bad as far as I can see. I think I’m pretty close to completing at least 4 out of the 5 before the end of the year. I’ll check back in December and see how it went. How’s your year going? Any goals you’ve set that you’ve either achieved or are on your way to do so?

Filed under: Experiences, Freelancing, WordPressTagged with: ,

Reflections on ‘me’, version 4.0

Today I reached a milestone in my life, what is otherwise known as the ‘big 4 0’. I turned 40.

It’s been a bit of a recurring joke in my household that I’ve been dreading the day, more so because I tended to make (half joking, half truthful) comments about the fact.

Now that the day has come and gone, if nothing else, I’m happy that it is here.

I’m not usually one to make a big deal out of my birthday (in fact for my 30th I pretty much hid away from everyone) but I’ve found that I’ve actually been quite happy to let people know that I’m turning 40 today.

Looking back at the last 10 years of my life I can’t help feel that I’ve accomplished quite a lot in a fairly short space of time. I got married, moved house, changed jobs, became self employed, sired two boys, opened my own martial arts club, discovered just about the best open source community out there (that’s you, WordPress peeps) learned a bunch of new skills and learned a whole bunch about myself along the way. That’s not to say things were plain sailing, but I can say with certainty that I definitely handle failure and misfortune better than I used to. I still have my bad days, but I don’t believe they are as intense or drawn out as they used to be.

I’m pretty sure I didn’t have a mid life crisis (although my wife might disagree) and I’m hopeful for the future in that I really do feel like I am where I am supposed to be right now, in order to take the next big steps for the next 10 years.

So roll on 50, I’m looking forward to looking back at another decade with a smile on my face.

For now, I’m just going to enjoy my Whisky and go play some Shadows or Mordor!

 

Filed under: ExperiencesTagged with: ,

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.

Filed under: Development, Freelancing, WordPressTagged with: , ,

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

Filed under: Development, Divi, WordPressTagged with: , ,

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/

Filed under: Development, Divi, WordPressTagged with: , ,

WordCamp Cape Town 2017

WordCampCapeTown2017

So last year I blogged about my list of resolutions for the new year. As with most resolutions it was a long list of the things I want to do differently in the new year, with very little grounding in reality. Reading that post now I can’t help wonder how I thought I was going to manufacture all that extra time!

Two days ago I sat staring at all the Make Slack channels I had joined in the course of the year and the realisation dawned that I was trying to keep too many fingers in too many pies when it comes to contributing to WordPress.  It struck me that I had to choose one (or maybe two) avenues within which I want to contribute back to WordPress this year and focus my spare time on those.

What I didn’t realise then, but I do now, was that I had already made the decision of what to focus on this year, merely by my actions last year, things that had already been set in motion during 2016. Once I realised that, it was very easy to leave all the other channels and look ahead to my journey with WordPress in 2017 with renewed purpose.  That purpose, building the community.

Which leads me to the real point of this article, an announcement I’ve been sitting on for a few weeks now and one that I’m happy now share with the world. I’ve applied (and been accepted) as the organiser for WordCamp Cape Town this year. It is a role I didn’t expect to take on until 2018 but circumstances have sent this my way and I’m happy to take on the challenge.

I’ll be blogging about my experiences here, mostly to record the journey from my own perspective but hopefully to educate and inspire others to either join, start or become a part of their own WordCamp’s around the world.

So here’s looking forward to WordCamp Cape Town 2017. Hopefully I’ll meet you there and we can share a WordPress story, or even just a coffee.

Filed under: Experiences, WordPressTagged with: , ,