Fixing Features First

I’ve always been fascinated by people who simply complain about things that are within their power to change, yet they don’t seem willing to actually make that change.

It’s like complaining about your countries president, and then not turning up to vote.

I’ve seen this often in the WordPress world, recently specifically about XML-RPC, and a few of those complaining haven’t contributing jack squat to core (other than conversations)

Something I don’t like about core is how authentication works with the WP-API. But…I’m actually trying, in my own time, to see if I can figure it out before I go wading into deep waters of emotional conversation on – too often people weigh in about features without checking their emotions or before attempting/suggesting a solution.

As a long time plugin and theme developer I appreciate customers who have tried to solve the problem first before complaining at me. I happily apologise when things are broken, but I’ll always go the extra mile for those who have shown initiative!

Perhaps rather try a fix first next time?


Joining Automattic

After the recent acquisition of WooThemes by Automattic, I’ve officially accepted an offer from Automattic to be part of their team as part of the acquisition.

And so ends my 6 year journey with WooThemes, yet it carries on as I’ll still be working on WooThemes products like FlexSlider for the foreseeable future. Follow me on Github for any open source stuff I do in the future.

What does change is my involvement in side projects.

So, I’m officially making my jQuery plugin free as of 1 July 2015, and I’ll be selling off a bunch of my WordPress and software related domains and websites.

I’m also going to do a complete refresh of this site, the content will remain but it will be more blog focused, specifically on WordPress and JavaScript.

Here is a list of stuff for sale, preferably to people wanting to carry on with what I had envisioned for the sites, I’ll add links as soon as they go up for auction, mostly on

  1. – Bid Now to Own!

Why Themeforest authors why….

So….all this commotion regarding the Slider Revolution plugin being bundled in themes has caused quite a few headaches for people. Myself included…

I spent a fair chunk of an evening this week “updating” a friends (staging) site using this theme -> to make 100% sure it was secure.

Here’s what I had to do…

  1. Backup the site – obviously
  2. Download the latest theme package from ThemeForest – fair enough
  3. Deactivate all the plugins – ok then…
  4. Delete all the plugins – huh? why? Oh right….cos you have your own custom installation of plugins….right….
  5. Upload the new theme – smooth, theme options maintained, hope restored.
  6. Reinstall and active the new versions of the plugins – worked well.
  7. Pour a double whiskey – because half the freaking content (such as slider images) is now gone/broken/i don’t know

So yes, I’m at a point of frustration now, because even as a seasoned developer on over 100 themes I now have to sift through backups of what SHOULD have been a smooth upgrade process just to fix the content. Loving it.

And before you ask, fortunately this wasn’t a live site, it’s a staging site, so luckily his live site isn’t buggered. And it’s not like I don’t like the Theme, just to be clear….just not this crappy plugin activation method.

Well now…that was fun….maybe I should start a marketplace?

Jetpack Photon image_downsize() issue

Sometimes in WordPress code you have the need to get an attached image, for example in a featured slider. To do this we make use of the wp_get_attachment_image_src() function.

The reason we do this is to grab the image properties such as height etc instead of just the url in order to add a property for dynamic slide heights.

However, there is a problem with this when a user is using Jetpack and the Photon service. Jetpack uses a function called image_downsize() which does not return the required image object/array. It simply returns the url.

So in the example below, height would not normally be able to be returned with Jetpack active:

$featured_height_id = get_post_thumbnail_id();
$featured_height = wp_get_attachment_image_src( $featured_height_id, 'full' );
$featured_height = ' height: ' . $featured_height[ 2 ] . 'px;';

However, I’ve added 2 lines that fixes this -the add_filter and remove_filter for jetpack_photon_override_image_downsize action.

$featured_height_id = get_post_thumbnail_id();
add_filter( 'jetpack_photon_override_image_downsize', '__return_true' );
$featured_height = wp_get_attachment_image_src( $featured_height_id, 'full' );
remove_filter( 'jetpack_photon_override_image_downsize', '__return_true' );
$featured_height = ' height: ' . $featured_height[ 2 ] . 'px;';

And before you point out that this is not technically Jetpack’s fault – it only occurs when using Jetpack Photon. Deactivate the plugin and all is fine and dandy. image_downsize() is in WordPress core (see link below).

Related Github issue here ->

image_downsize() codex ->

Offline Support

Four years ago this month I joined WooThemes. The time has gone pretty quickly and I’ve had some great times in the office, interacting with our remote staff, and of course the WooTrips 🙂

But what most people don’t know is how incredibly scary it was for me to take the job back then.

So here’s some context; my wife and I we’re newlyweds, married for less than six months and I was in a senior position at a well known development agency in Cape Town – WooThemes was not well known in South Africa at all, and the employees numbered 6. Oh, and there was no office phone number….and they were a fully online business….in South Africa….what the??

The general response I got from most people at the time was “that doesn’t sound right, it sounds very risky” – laughable now, but not back then.

The difference was that I’d used several WooThemes, I knew their quality, so I was a definitely a fan, but most importantly I had the unwavering support of my wife. I actually never applied for the job until applications had unofficially closed (I found this out after I was hired).  As I recall, it was a Sunday night when I told my wife about the position and she said “do it!”

So I applied, got a call the next day, went in for the interview the following day and was offered the job on the spot! Crazy but true.

2013-11-06 18.11.53

My wife has supported me every step of the way in my career, even when I’ve make mistakes, so what I’m saying is never underestimate those who support you and who you support – encourage at every opportunity, you never know who you might inspire!

WordCamp Cape Town 2013 is here!

WordCamp Cape Town 2013 is only a few days away! A few of us local Capetonian WordPress community members have been organizing this years’ edition after last years’ organizer decided not to pursue it this year, and it’s been a great experience getting to grips with organizing a conference.

So now we are in the final stretch, grab your tickets now, check out the awesome speakers and the lineups, and come say hi on Thursday – I’ll be roaming around as a happiness expert and coordinating a few of the volunteers. WordCamp is all about the community, so let’s connect, have some fun and be inspired!

[box type=”tick” size=”large” border=”full”]Buy WordCamp Cape Town 2013 Tickets[/box]

[box type=”info” size=”large” border=”full”]See the WordCamp Cape Town 2013 Speakers[/box]

[box type=”info” size=”large” border=”full”]Check out the WordCamp Cape Town 2013 Schedule[/box]




WordPress Heartbeat API example plugin – Pulse

One of the most important experiences for me at this years WordCamp Europe was meeting other people, specifically members of the WooTeam who I haven’t met before. One of them was Remi Corson, who after overhearing a chat I was having with Patrick Rauland, sat me down and showed me what he was working on with Heartbeat API.

It was an awesome chat! The power of collaboration between WordPress community members is so cool 🙂 and in the spirit of collaboration, I’ve decided to release an open source plugin that will help you get started with your own Heartbeat API development.

So check it out on Github, fork it, submit some pull requests, if we can make life easier for other WordPress developers wanting to use Heartbeat API in their products then that’s what I’m hoping for!

In the long term I’d like to contribute back to the Heartbeat API docs because they are severely lacking at the moment!

Pulse – Heartbeat API example plugin

WordCamp Europe 2013

I’ve had the privilege of attending the first WordCamp Europe the past 2 days with the rest of the WooThemes crew and it’s been awesome! I thought I’d share some of the highlights for me:

Old Avatars, New Faces

I worked on WordPress 3.0 for menus with a few people but I never met any of them in person…until yesterday! I finally got to meet Ptah Dunbar and he’s a pretty cool guy! But that was just the first of many WordPress pro’s I got to meet…for me this conference has been a revelation to me in terms of understanding the community better – and not relying on twitter avatars to get perception of people.

Some of the (other) awesome people that I got to meet:

That’s what I’ll remember about WCEU – the people and the relationships.  Even just hanging out with the WooThemes team and talking about code and ideas has been such an inspiration for me personally and professionally. Some highlights were talking about the Heartbeat API with Remi, and BuddyPress with Scotty B. Moments like that are priceless in a distributed team like WooThemes.

I’m hoping the talks videos will be online soon so everyone can check them out! And now I’m tired…sleep time! 😀

Check out my photos here and here.

Letting Go

I’ve worked on numerous products at WooThemes over the past few years, and like most things I work on, each one I’ve ended up developing an attachment to; after all I was creating something and much like a parent (which I can fully appreciate since the birth of my daughter) I want each product of my creation to flourish to it’s full potential. However, something that I found in the past that was very hard to do was to let go of the “thing” and see it in the hands of others, sort of letting it “fly” in a way.

The Problem

The problem with hanging onto a “thing” is that you (may) eventually lose your objectivity in terms of making decisions, well that’s what I’ve found as the original developer of a product. You sometimes lose sight of when to stop developing a project, to pivot, or to kill it.

At WooThemes I’ve seen several things I’ve started working on either fly or fail, and it’s a difficult thing to watch from the sidelines because so often I’ve wanted to dive right back in and “fix” it – the problem with that, is that usually no one wins! Not the project, not the people involved and certainly not myself.

I’ve seen the following examples in my career:

WordPress Menus/WooNav

I built WooNav as my first project at Woo and I’m still immensely proud of it, however opening myself up to the rest of the WordPress community and their ideas and thoughts for how it was going to end up as in the WordPress core was difficult. I’ll be honest, I didn’t agree with some of the initial decisions, but it turned out for the best for WordPress. And that’s the bottom line, it wasn’t about me or what I thought was best for the product, others have done a fantastic job of taking what I originally built and making it far superior than that initial commit. It’s good to be wrong every now and then!


Another of my early Woo projects, our Tumblog themes/plugins arguably gave rise to and increased the prominance of the popular “tumblr” style WordPress themes. Eventually things led to post formats being included in core, of which we had nothing to do with directly, but I do think that ultimately the Tumblog functionality influenced the community in a positive way. Over time the plugin popularity has waned and isn’t even necessary for a tumblog style design because all that goodness is in core. So the Tumblog plugin will eventually die, much like Woo’s Tumblog themes, and that’s not a bad thing – may it rest in peace.


Sensei is my current development project at Woo and I’m super passionate about it and education in general, but more recently other members of the team have been getting involved in the development of the core code and it’s been awesome! I originally had a definitive direction in my head, but it’s been nice to let go and allow others the breathing room to run with ideas and build it without having to “run it by me.”

The Point

If you are a product visionary/original developer and are building in a team environment you need to be able to take a step back and allow others to embrace the product as their own – this allows for greater creativity and opens the product up to new ideas and can help elevate it to greater heights.

Self Commenting Code

So…a colleague of mine, posted a tweet today about self commenting code. I briefly replied, along with others, and I thought I’d share some of my thoughts on “self commenting” code and standards.

Whose rules are you following?

First things first, who defines what is self commenting code? I guarantee you that different developers will see code and comments differently. For example, a php developer who is used to a rather loose language structure, will think differently from a more structured C developer when it comes to commenting their code.

There are different interpretations based on different standards, and one such standard I have researched and written about is the Construx CxOne standard based on Steve McConnell’s work. And even by using such a standard as guidance, some of the standard is specific, for example naming conventions and formatting of variables, while other parts are vague, for example in section 1.6 under commenting “Remember the comment audience

With that said, let’s take this one step further…

Developer Career Levels

If you have been coding for 10 years (or even 5), think back 5 years and ask yourself if you know more or less than what you do now? That’s fairly simple, however, ask yourself if you are a better developer?  Who defines what “better” is – is it a feeling or do you use a metric such as a standard to govern this? Or is it your practices and habits (such as commenting and naming conventions)?

But all that aside, simply think of working in a team with junior and senior developers. I’ve had this very experience at a previous job where one of the senior developers and I had to work together on a project, and he had his ways and I had mine – whose way is better?

But is that even the right question? The real question is, when it comes to coding together is communication. Can I communicate effectively through my code to other developers. If the senior developer on the above project used super complex code with no comments, I would have been screwed and the project would have suffered. But we had defined coding standards before the project began so we knew what to expect. The same should be seen in the WordPress community, as WordPress has set code standards.

Let’s go a bit further down the rabbit hole…

Code Frameworks

Some frameworks use camel casing (but is that upper or lower camel casing…) for naming conventions of variables and functions, some have coding patterns like MVC, MVP, or n-tier, and some use docblocks to generate API docs to elaborate on there instead of the code – and here again it’s worth noting who is the audience? WordPress is a fantastic example of this – the Codex serves the community far better, in my opinion, than tons of comments in the code.

Onwards to my final point…

Who cares?

Ultimately this argument is subjective and people will inevitably have an opinion one way or another, because people are different and like to have their own opinion (just take religious arguments as one example) – the main thing here is to communicate well, if you do that well through your code, then you’ve already won!