Bend WordPress Meetup Gutenberg Notes

Last night the 2nd meeting of the Bend WordPress Meetup took place at the beautiful OSU Cascades Campus. A nice crowd of friendly folk attended to hear me chat about Gutenberg! As promised, here are the slides from last night, along with some helpful links that came up during the talk and Q&A at the end.

Great Blog Posts To Read

Here are the blog posts that I think you all should give a read based off of our conversation last night:

The Giphy Example Block

If you are interested in checking out the code used in the "How To Build a Block" part of the talk, you can find it up on GitHub. Pull Requests welcomed. And of course, here is my favorite gif from last nights talk:

Other Items

Based off some of the questions, here are some issues in the Gutenberg repository to check out:

Get Involved!

Again big thanks for spending your Tuesday evening with me… and I encourage you all to install Gutenberg on a site and use it to write real content if you can. Please do join in the discussion on the project in the #core-editor Slack channel, or peruse the GitHub issue list and chime in on all the things.

Hello Gutenberg!

A week from today I will be giving a talk at the Bend WordPress Meetup entitled Hello, My Name is Gutenberg – and being the huge procrastinator, I am finally getting around to writing an intro post to the talk ( which helps me actually mentally plan my talk ).

Get To Know Gutenberg

So if you are planning on coming to the meetup, that is awesome! I wanted to give all that will be in attendance some homework to do prior to the meetup which might make the experience even more awesome for you. So here are some links!

  • The GitHub repository is a great place for developers looking for more technical insight into the project.
  • Questions? There is a list of FAQs in the repository too – but please come to the meetup with all your questions!
  • Matt just made a great post about some of the Why's behind Gutenberg. I highly recommend giving this post a read.

But the best way to really get to know the project is to install the plugin and kick the tires a bit!

Testing It Out

If you have some time, it would be great to spin up a test site ( if you don’t have a WordPress test site handy already ) using poopy.life. Once you have your test install running, go to Plugins | Add New and search for Gutenberg. Install and activate the plugin and you will be ready to test!

When the plugin is installed, you will now have a Gutenberg menu item in your sidebar. Expand that menu section and click New Post. Write yourself a post like this one with images… try pasting in content from other sources, or URLs and see if things auto-embed. Take notes and please come ready to share your experience with the group!

The Talk

Okay back to the Meetup talk – we will likely run through the same steps above during the talk, but will also look at how to create a custom "block" for use in the new editor. I will likely make a new post once the code for that part of the talk is ready ( remember, procrastinator here ) so those that would like to can get a look at the code prior to the meetup.

Looking forward to seeing you all next week!

How To Setup a WordPress.com 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 WordPress.com 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 WordPress.com API

In order to perform certain operations with the WordPress.com 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 WordPress.com 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 https://github.com/Automattic/node-wpcom-oauth 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 WordPress.com 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.

settings_example_json_—_calypso-pre-oss.png

Now paste in your freshly minted client id and client secret from your new WordPress.com 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.

WPOAuth.png

Now you will be redirected to WordPress.com 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 legendeoftimmy.wordpress.com.  Click Approve to get the token.

Authorize_Legend_of_Timmy.png

Now you will be redirected back to your localhost app, which will use its secret and the token returned from the WordPress.com 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 WordPress.com 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.

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

Installing WP-CLI on OS X Mavericks

The Backstory

A recent project has me working quite a bit with WordPress and WP Plugin development. After getting my sea legs on the subject of Plugin Development, I started going down the path to writing tests for the plugin I am developing.

$this->assertEquals( ‘testing_framework’, ‘PHPUnit’);

PHPUnit is the testing framework used on WordPress Core, so I decided to use the same framework while writing my tests. It has been a bit of a learning curve for me to get started with testing a Plugin, so this is the first in a series of posts I will be writing about getting a testing environment setup on OS X Mavericks.

For the record, my local setup is a Macbook Pro that is running OS X 10.9.2, and the Apache/PHP/MySql services are being handled by MAMP. MAMP is pretty straightforward to get running so I’ll move ahead to the subject of this post – WP-CLI.

The WP Toolbelt

My first exposure to WP_CLI came when I was looking for a less painful way to perform upgrades on The Longboard Blog. For anyone at home on the command line WP_CLI just feels right. For example, when our marketing person wants some hot new plugin installed, I just fire up an ssh session and jam in `wp plugin install omg-internet-cats` to install her desired plugin.

But on my quest to TDD WordPress Plugin nirvana lead me right back to WP_CLI. You see to get the test suite setup and running easily, WP_CLI is a key ingredient.

Installing WP_CLI

First things first, grab some handy info to complete the install. First of which is firing up MAMP’s start page (likely here if MAMP is running: http://localhost:8888/MAMP/?language=English) and grab your PHP path from the phpinfo tab. It will likely be /Applications/MAMP/bin/php/php5.5.3, with the last directory varying depending on your PHP version.

Next the install is super quick and easy, just cd to your MAMP php directory and do the following:

curl -L https://raw.github.com/wp-cli/builds/gh-pages/phar/wp-cli.phar > wp-cli.phar

Verify it works:

php wp-cli.phar --info

And create a shortcut:


chmod +x wp-cli.phar
mv wp-cli.phar /usr/bin/wp

Then the only unique part of the install is to add in some convenience aliases to your ~/.bash_profile. From the command line again run:

vi ~/.bash_profile

And append the following to the end of your profile, be sure to adjust the path to your MAMP path you looked up in step #1:

Now if you open up a new terminal window, or source ~/.bash_profile you can start wp‘in like a champ. Stay tuned for the next post in the series about setting up the PHPUnit test stack in your project.

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.

RTFM

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.

Decorate

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:

Initialize

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


Decorators.register! Rails.root

SMS Shipment Notifications via Twilio

Since the dawn of interweb commerce, etailers have been serving up e-mail based alerts when a package is sent out the door. The shopper then clicks on some form of tracking link within that email, and the waiting game begins.

Email Shipment Alerts: The Meh

So this process does work, but we all know the downfalls of this route. Email of course is just broken in general, but more specifically, shoppers will often mis-type their emails during the checkout process, or notifications such as these often get routed directly to a SPAM folder.

Sprinkle in Some SMS with Twilio

Now I am not advocating for the omission of shipment emails, rather simply giving your customers an alternate channel to receive these alerts. We are big fans of SMS messaging at The Longboard Store. We already let our customers subscribe to text alerts for products that come back in stock, so we figured why not let them get notified via SMS when their package ships out?

Last week we did just that. A simple form was added to the order status page, allowing customers to sign up to be alerted via text when their order is shipped. The system lets customers add multiple phone numbers to be signed up to the alert system – and like the product alerts – requires users to validate ownership of the mobile device via a confirmation code.

Neat, but Why?

In the first week of this system being online ONE THIRD of all customers who placed an order signed up. Rub your eyes, read it again, thirty percent of all customers placing an order signed up to be notified via SMS when their order ships.

The people have voted, and they want to be notified immediately when their new toy ships.

The text alert simply states their order has shipped, and the user can click on a shortened URL that directs them to a shipping status page where they can track the package. Perhaps down the road we can send an additional alert when UPS marks the package as out for delivery….

Give The People What They Want

Ultimately this again shows that SMS is an effective means of communicating in the online retail space. Quite possibly our demographic (longboards and skateboards) skews the interest in SMS a bit, but I believe that similar interest would be seen amongst nearly any online marketplace.

Plainly put though, by offering these types of notifications, you are adding just a little bit of extra customer service for your shoppers… besides, who wouldn’t be excited to see that their package is enroute?

I’m excited to see CTR on these text messages, and possibly see if any up-sell opportunities exist for these clicks.