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 -> https://github.com/Automattic/jetpack/issues/607

image_downsize() codex -> http://codex.wordpress.org/Function_Reference/image_downsize

Knowledge Revenue, Twitter, and APIs

I saw this tweet today and it reminded about something I realized quite a long time ago about online companies and knowledge revenue.

APIs

If you are an online service and you are gathering user information, or even information about how people interact with your service, there will always be the possibility to monetize that (assuming you have your privacy policies in place).

That means that, in theory, every online company has the potential to create a knowledge revenue stream simply by creating a relevant API for 3rd parties to access.

The Value in Community

The beauty about using API’s is that it allows 3rd parties to start building a community around it; by building apps, mashups with other services, creating extensions for the core product, etc etc.  Oh, and not to mention the benefit of having the 3rd parties drive business to your company – because it will benefit them and your company.

Take WooCommerce for example (this example is close to home for me, working for WooThemes) – the core product is free, WooThemes makes no money from it, but the beautiful thing about WooCommerce is how it has been developed; it allows you as a developer to “extend” it by building plugins that add or modify the way it works.  And that has helped grow a very large ecosystem around it.

Knowledge Revenue is Gold

So, in summing up…Twitter & Facebook…are pretty much like Google (on a lesser scale) as they are all actually mining information.  They aren’t just a web app, they are semi-intelligent data miners, and that information is gold.

And just like a gold mine, not only are they listed on the stock exchange, but you can expect to pay for that knowledge/gold in the future, and in turn making them a lot of money.

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!

Ghost Reporting

So late last week, over at WooThemes, we released a free theme for the latest content publishing platform, Ghost, and it’s rather appropriately called “Swayze” (in honour of Patrick Swayze’s appearance in the movie “Ghost“).

For those that don’t know, Ghost is a platform built on top of NodeJS mostly using the Express framework. Now I’ve been dabbling in Node at Woo, building stuff for our support staff in the Zendesk support platform, as well as another internal system that I’m (still) trying to master.

However, building themes for Ghost is actually quite a simple process! All you really need to do is read the docs 🙂 and learn how to use the Handlebars framework. That’s it! My part in the process of releasing the theme was simple – after Cobus had build the design into straight HTML markup, I learnt the templating system and converted the html into the .hbs layouts and integrated the Ghost and Handlebars tags.

Go check it out here and let me know what you think!

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!

Tumblog

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

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!

WordPress Cape Town Meetup with Matt Mullenweg

Last night we had an awesome WordPress meetup in Cape Town at Sinn’s restaurant in the city centre, and none other than Matt Mullenweg was the guest of honor! It was great chatting to him and meeting him in the flesh. We chatted about MP6 plugin, REST API’s and where WordPress is going in the future. All in all a fantastic evening!