How To Setup a OAuth Token

In about a month I will have the distinct honor of speaking at my first WordCamp – WordCamp US in Philadelphia!  I’m quite excited for the talk and to prepare for it, I will be doing a series of How To posts that will be referenced during the talk.

The title of the talk is Gamification with the API and is focused on interacting with the API using wpcom.js and node.  This first post covers how to easily get an OAuth token to work with endpoints that require authentication.


OAuth and the API

In order to perform certain operations with the API, like creating posts, or getting access to any protected information, you must come equipped with an OAuth token.

This process can be lengthy, but fortunately there is a quick example node app that will help expedite this process for you.

node-wpcom-oauth To The Rescue

The fine folks at Automattic have an npm module that handles server-side oauth tasks with the API, and inside the repository there is an app you can use to get a token.  So the first step is to download a copy of the repository.

Then if you change directory into /example you will find the app, and a set of instructions on how to use it.

Create an App

In order to use the example application you will first need to create a App.  To do so, visit the App Dashboard and click “Create New Application”.

The form to create an App is pretty basic.  For the purposes of my talk, and my App, I will likely be the sole user – but if you plan on having a more public-facing application, some greater care/thought might be put into a name and description.Developer_Resources___Create_cool_applications_that_integrate_with_WordPress_com.png

For obtaining the token, you can use the same Redirect URL as seen above “http://localhost:3001/connect/res” though this is also configurable in the example application.

Once you submit the form, you will be redirected to a success screen like so:

Developer_Resources___Create_cool_applications_that_integrate_with_WordPress_com 2.png

Click the name of your App, highlighted in red above to get back to the full detail page for your app, which also has the needed information to complete the OAuth token process.

Client ID and Client Secret

Now on your App’s page you can scroll down to view your OAuth Information.  You will need both the Client ID and Client Secret for the next step.  These are secrets, treat them as such.  Shhhhh:

Developer_Resources___Create_cool_applications_that_integrate_with_WordPress_com 3.png

Configure The Example App

Okay with your newly found secret information in hand, or in your computer’s clipboard, head back to the [code]example[/code] directory in the node-wpcom-oauth project.  Inside the folder you should see a file named  settings_example.json – go ahead and rename that to settings.json and open the file in your text editor of choice.


Now paste in your freshly minted client id and client secret from your new App, and save the file.  Now open up a command/terminal application within that folder and type node index.js.  This will startup the example app on port 3001.  Now visit http://locahost:3001 to start your token adventure.

Get Yer Token

The first screen will confirm the settings you just created, and then give you a link to “GET THE CODE” – confirm the settings look good then click the link.


Now you will be redirected to where you can select which of your blogs you would like your App to be able to access authenticated as your user account.  For my example app, I have created a site called  Click Approve to get the token.


Now you will be redirected back to your localhost app, which will use its secret and the token returned from the side of things to prepare for the final step to actually get the FINAL TOKEN.

WPOAuth 3.png

Click “LETS GET IT!”.  Seriously, last step right there.

Great Success!

You should now have a screen with your bearer token.  And now the entire world of the API is ready for your creativity:

WPOAuth 4.png


Redemption via JSXHint

Recently while shipping a feature for an awesome ReactJs app we have been working on at Automattic I made the mistake of removing a variable declaration that resulted in a dreaded undefined error on production.

But like life, in coding we learn from our mistakes, and work to prevent them from happening in the future. Obviously a test framework wired in with CI would have likely caught this – but the error only happened on certain sites – making it somewhat of an edge case that some test cases would not have caught.

A simple quick run thorugh jsxhint would have caught it though.

Simply but jsxhint is:

A wrapper around JSHint to allow linting of files containing JSX syntax.

Installation of jsxhint is done via npm, and by using the global flag: npm install -g jsxhint

I thought, wouldn’t it just be neat to always run jsxhint on my revisions prior to committing them?

After a bit of searching, I found an answer on stackoverflow detailing how to setup a git pre-commit hook for jshint. So with a little bit of massaging, I created a pre-commit git hook that runs all changed .js and .jsx files through jsxhint. You can find the pre-commit hook here.

If jsxhint finds any errors in any files changed in your revision, it will not let the commit proceed… and wonderfully it prevents James Van Der Beek from shedding any more tender tears.

Extending Rails Engins with the Decorators Ruby Gem

Over the past month I have been launching a few sites using a neat little Rails engine called Piggybak. Piggybak (worth a blog post on its own) handles just the basics of an e-store, and leaves the rest up for the creative developer.

While building these sites I would run into scenarios where I needed to extend the engine’s functionality and I went searching for an elegant “railsy” way of doing so. My search led me to some threads from the Forem project, and ultimately to the Decorators gem.


I couldn’t readily find any how-to’s on the gem so I dug into the code, and the usage in the Forem gem. It is super simple to use, but I figured I would add some documentation here on the blog. First things first, to utilize Decorators in your rails project add it to your Gemfile

gem 'decorators'

The gem does have some opinions on how one should construct their decorators for Rails engines. I based my usage upon what was found in Forem and created a decorators folder in the app root of my Rails.root. Within that folder, one should then create folders that mimic your extensions/decorations to engines (i.e. /app/decorators/models, /app/decorators/views etc), and the decorators themselves need to have a suffix of _decorator.rb.


So lets decorate the Piggybak::Order model to include an association for packages. Following the folder structure above, we would create a file at /app/decorators/models/piggybak/order_decorator.rb like so:


The last piece to take care of is add the following line to a config/initializer file:

Decorators.register! Rails.root

Conversion Analytics Nirvana: Clicky Stats + High Charts

I often find myself being caught in the time sucks of Google Analytics and Clicky Stats. When I code a new feature on a given site, I’m very eager to see how the greater masses of the web use my shiny new feature, but most often I end up sinking too much time clicking around these third party services… when I should be like writing code and stuff.

Conversion Tracking – What Sources Convert?

To me though, the most useful data form any analytics packaging, for an ecommerce site at least, is researching what sources are converting. The uses of this are obvious, and endless, so yesterday I decided to make it a little bit easier for the users of our admin application at The Longboard Store to get in touch with conversion tracking.

Clicky API, Serving Up the JSON Data

I am a big fan of Get Clicky. It is simple, easy to use, and even has some fun features like ‘Spy’ and ‘Big Page’. But the feature I like most is their dead-simple API. So with the final half hour of the day ahead of me yesterday at work, I decided to leverage that API and Highcharts to build a quick view into conversion sources.

Look Out, Psuedo Untested Code

Hackity Hack time ensued, and I whipped up a quick little bit of jQuery and Highcharts to build a Pie Chart of conversion sources.

Essentially I have a button with an id of ‘clicky-chart’, when the user clicks that, the Clicky API is called and a pretty Pie Chart is painted like so:

Make Everyone an Analyst

The wonderful thing about quick features like this is it empowers users of your drab admin tool to really analyze data a bit further. If you dig into the gist above, you can see that when a user clicks on a slice of the pie, a new window is opened to the clicky stats detail page where they can dig into a given group of conversions in finer detail.

Getting this data in front of more users helps foster new ideas, and helps easily identify under-performing marketing channels.

I might abstract out this code a bit to make generating HighChart graphs from the ClickyAPI a bit easier too. We’ll see!

Meet Flipper – A jQuery Plugin to Change Image Src on Hover

Although we do come up with some original ideas at The Longboard Store – we too find inspiration from other online stores as well.  So my boss sent me a link to a Macy’s page and had me hover over some of the product images.

Thus Flipper was born.

Flipper is a super-duper small jQuery plugin that facilitates swapping of image sources on hover. It doesn’t do any fancy fade affects like the one on Macy’s (it could, but why?), but it does pre-load the alternate image for a smooth flipper experience. Now board shoppers can checkout the top and bottom graphics of the boards – all from the same page!