How The WordPress REST API Changes WordPress Plugin Development

Over the last few months I’ve been working on creating a totally self-contained WordPress A/B testing plugin. It’s called Ingot, and we released version 1 right after christmas.

Since I did almost all of the development myself from scratch I was able to do it all “the Josh way” and refine what that even means. This allowed me to put a lot of my opinions on WordPress development to the test. I shared a lot of what I learned in yesterday’s post.

Lessons Learned Coding A Big, New WordPress Plugin

Ingot was in many ways written around around the REST API. The custom endpoints we built are used for the Angular app that Roy Sivan and I created for the admin screen. It’s also used in a very small front-end JavaScript file for tracking conversions, failed conversions and cache busting.

Today, I wanted to follow up yesterday’s post with what I think it means to create a WordPress plugin using the REST API. Next week, I’ll talk about the business and product design lessons I learned from Ingot. The design decisions that went into building the Ingot REST API will be a big part of that discussion.

How Things Change

As most people reading this know, I spent a lot of time over the last year or so thinking about how the WordPress REST API will change how we build WordPress plugins, themes and apps. I think this change is big and has to do with how the use of WordPress is changing.

WordPress didn’t get to 25% market share on blogs and it’s not going to get to 50% or whatever that way. The growth comes from eCommerce, publishing, membership sites, inbound marketers etc. These are all users that can benefit from being service providers.

Photo by: Jeff SheldonI think that those of us who empower these users by giving them the tool need to make their sites have to think API first. Your plugin’s interaction with the client is going to be more and more coming through the API.

That doesn’t mean WordPress plugins are suddenly all JavaScript magically. Your custom REST API routes are PHP code that you write around the rest of your plugin.

If the code they wrap must be solid and sufficiently decoupled from input method — if you call GET or POST in your CRUD still you’re not going to make this transition.

The hype around the WordPress REST api has been about the default routes and that might be exciting to you if you do front-end work. But the real potential in my mind is that your plugins can be repurposed SAAS service more easily and that your users can become service providers themselves.

The Developer End User

Photo by: Sonja LangfordToo often, when creating a plugin that is designed to be simple to use and not require technical knowledge, we forge that there are still developers as end-users. Keeping developer end-users happy is super important as they are often decision makers that choose whether or not their client uses your product or not. They are also likely, if happy, to become evangelist for your project.

The ability for developer end users to be able to customize and integrate with your plugin via your REST API as an alternative to learning the WordPress hook system is a big deal. It opens more doors and more opportunities. It means more integrations, more contributions and more potential developer evangelists.

Angular + REST API

I originally thought I would use the plugin generator that David and I use for CalderaWP plugins. I couldn’t make it work with the original DB structure I had. The first Ingot demo used a really bad UI I hacked together. I wrote a ton of PHP code full of admin-ajax callbacks and functions hooked to init in order to check for incoming form submissions. By all objective standards, it sucked.

So, I taught myself AngularJS.

Since I was trying starting at a Jon Snow-level understanding of AngularJS, I was bugging Roy Sivan for help a lot. Roy ended up doing a lot of the heavy lifting for me and now pretty much owns the Ingot UI. That’s awesome because I don’t like UI work and he’s better than me.

Photo by: Jonas NilssonBut, I did learn a ton about Angular. What I learned enabled me to write all the example code for the last section of my WordPress REST API course — Angular front-end for WordPress sites. I really like Angular and the angular-ui router. It’s a really great way to work. It almost makes me wish I made WordPress sites so I could make them with Angular.

Our admin doesn’t look very WordPress. It’s a very standard Bootstrap, which is a common pattern that I hope people are used to using. I would love to get a WordPress admin Bootstrap theme made soon though.

I’ve spent a lot of time in the past trying to force the MV* pattern on WordPress, which is insane for a lot of reasons. Using the WordPress REST API to provide data to Symfony or Angular is really great, and fairly simple.

A WordPress plugin, like any product is only as good as its interface. I’m convinced that working with Angular and custom WordPress REST API endpoints was the right decision in terms of UI/UX. It also means we have a solid REST API to use if we make an Ingot SAAS product or if end users want to use it.

This Is The New Way

At this point, I don’t think it makes sense to build a plugin without its own set of API endpoints. Doing so requires a PHP CRUD that is sufficiently decoupled from input to work seamlessly with the API. Writing your plugin knowing you will use the REST API makes dependency injection in your class design a necessity.

That’s going to be an issue for a lot of older plugins, and the backwards compatibility challenge is also there. I think it is worth the rewrite though, if this is an issue. This will make your plugin more easy to unit test, which is a great bonus.

Photo by: Jerry AdneyOlder plugins also have to deal with backwards compatibility concerns. Ingot requires WordPress 4.4 or later. It’s a new plugin so we don’t have a user base to worry about alienating. It’s a concern for me in my existing plugins, and we will see how that plays out as I modernize them to work around the REST API.

I will, because I think that plugins that do not embrace this new way risk being left behind. For new plugins, the REST API-first approach makes sense. It leads to better admin experiences, easier interfaces and allows your plugin to more easily become a part of  a stack that is not totally built in WordPress.


Lessons Learned Coding A Big, New WordPress Plugin

Over the last few months I’ve put a lot of time into writing Ingot — an automated A/B testing and conversion optimization plugin for WordPress. Because Josh, I did a lot of other things at the same time — but Ingot was my biggest project.

Ingot is probably the biggest plugins, in terms of lines of PHP code, that I wrote. I’ve worked on bigger plugins, but never as the primary developer. Pods and Caldera Forms are bigger, but my contributions code-wise to those are not huge.

For Ingot I wrote all of the PHP code. Roy Sivan helped me build the admin interface, which is an Angular app. He was also a valuable sounding board and bug catcher for the rest of the plugin.

I wanted to share some of the lessons I learned, as a developer, writing a big plugin. Writing this plugin from scratch allowed me to put to test a lot of my personal opinions on WordPress development. I’m going to follow this article with one specifically about coding a plugin around the WordPress REST API and another with some lessons I learned as an entrepreneur from the process.


Separations of Concerns

Working with the WordPress REST API helps encourage separation of concerns because of the way defining routes breaks up the process of preparing, processing and responding to requests. In addition, knowing that some of your CRUD will happen via your REST API, but not means you either have to wrap your API callbacks around a standard set of CRUD classes, or you need to keep two ways of reading/ writing/ validating and sanitizing data in sync.

The latter of those two options is insane. I went for the first. Ingot has a CRUD class for each of the different data types — test groups, variants, sessions, click tracking, settings — each of which extends a base class. Having separate CRUD class keeps the validation, sanitization and DB writing separated from every place that CRUD is ever used, including the REST API routes, and objects that represent groups or tests.

This also led to having one class to handle read/writes and  establish a pattern for using CRUD, along with smaller extending classes to define what fields are needed. I liked working this way. Even though these classes are likely to be called multiple times, I used all static methods for them. Yes, there are objects for single groups, tests and sessions that are often needed, but CRUD is just a collection of functions and without any application for an iterator, having to instantiate multiple objects of these classes wouldn’t have provided any utility.

I think of these classes much like how WordPress core’s WPDB class, which might as well be all static methods since we always use one instance, relates to WP_Query. We use WPDB to inject post collections into specific WP_Query objects that we can then iterate over.

The way I worked wouldn’t have been doable without late static bindings. In non-static methods, $this refers to the current object. So if the class is extended, $this is the object of the extending class. The self keyword doesn’t work that way. self in the parent class refers to the parent class, not the subclass extending this.

On the long list of reasons why I didn’t hamstring myself with conventions of a language that is almost 8 years out of date (PHP 5.2) is late static bindings. Late static bindings allow for static inheritance. The keyword static functions like self, except it can refer to a subclass method or property if one exists.

One thing I’m really proud of in Ingot is that I stuck to very small classes. For example, I have a class that creates a conversion rates stats object. This is separate from the class that creates an object for stats for all of the variants in the group, which is a collection of the objects of my conversion rates stats class. This creates re-usable code — the conversion rate class is used for variant and group stats, easier testing, and avoids code reuse.

Small, reusable classes are not just neater and more testable, they make refactoring easier. I rewrote about half of Ingot in the week before release. Short story — CRUD was overcomplicated and the testing algorithm was going to require tons of traffic, which would be a problem for a big part of our target audience. That’s a different discussion, but my point for today is that small classes meant more saved code during that refactor since it was very easy to separate the parts that still had a job from those that didn’t.

This is a concern moving forward. I am considering whether it makes sense to break the plugin into smaller Composer packages that I can assemble into different, smaller, task specific versions. Doing so could also allow for implementing a CRUD system that uses the posts and postmeta table instead of custom tables.

Composer & Dependency Management

Photo by: Steven SpassovI used Composer for dependency management and providing a psr-4 autoload. There is a ton of blog posts out there on why I love Composer and dependency management in general. The PSR-4 autoloader forces a directory and class naming structure on the plugin that makes it highly organized. Between that logical organization and being meticulous about inline docs, I think the code is easy to follow. We will see as other developers get into it.

I did hit some stumbling blocks with dependency management. I used Composer’s file map for including PHP files that are not classes, which I found to be annoying. Classes are added automatically to the autoloader, since it is based on logic. File and class maps are static lists of files and adding to them requires a composer update, which I didn’t always alert Roy to, causing unneeded errors on his end. It also makes switching Git branches a pain.

I chose to use Bower for managing JavaScript and CSS dependencies. Bower is a pretty slick tool, but ZIP file for the first beta version after I started using Bower was 2 or 3 times the size of the previous version. This was because I was enqueuing the scripts from bower_componets.

My solution was to use bower-installer to copy all of the main files — IE the ones I needed — to a separate directory. This allowed me to exclude bower_components and all the extra stuff from the final zip.

I went on a bit of a quest to reduce the file size of the zip files I was creating for releases. Another big win was setting this command in my build script:

composer update --no-dev --optimize-autoloader --prefer-dist 

This pulls in the Composer dependencies without their Git repos, or unit tests and optimizes the autoloader. Even with just a few dependencies, the file savings were pretty nice — about 6GB. Git repos are big.

Since the plugin is in a public Git repository I don’t think removing all this extra stuff that most end users don’t need does anyone a disservice or reduces their rights to modify the software. If an end user is a developer and needs the whole package, they can get it on Github.

I actually used very minimal third-party dependencies. But my testing library, the one I switched to later on, started out as a third party dependency. The library I used was built to use Redis to store data. So, at the least I needed to add a way to store data using my CRUD system.

Photo by: Marta PawlikAt first I kept the testing library checked out from the original source — and that author merged my pull request to fix a bug I found. In order to facilitate this I kept my class to save data using my CRUD in Ingot instead of in the library.

As I found more places where my usage of that library wasn’t fitting well with the original design, I had to make more changes that didn’t make sense as pull requests. So, I started using my own fork and making changes directly there.

I will soon evaluate if my fork makes sense on its own, as a version of the original that stands on its own and is useful to have as a separate project or if it needs to be absorbed into Ingot fully. Either way, being willing to dive into a dependency, learn it, and modify was the difference between throwing it out and having to do another huge refactor and being able to ship the plugin on time(ish).

Iteration vs Throwing Shit Out

Photo by: Rick WaaldersI had a lot of fun with this plugin. Working on something that doesn’t have any users yet is really nice. Once a project is released backwards compatibility and stability are concerns. When you’re iterating on something pre-release, you get to break stuff and start over.

It’s funny how quickly I can fall into the “fix it, don’t break it” mode out of habit that comes with maintaining plugins with lots of active users or contributing to WordPress. I literally had to tell myself a few times “don’t work around that bad design decision, you wrote it yesterday.”

As I said before, I re-did the base A/B testing algorithm pretty late in the process. This led to re-doing a lot of the CRUD and re-working the REST API and a lot of other parts of the plugin.

The lean startup mindset dictates the idea of getting to a minimal viable product quickly and improving it from there. WordPress preaches the idea of continual iteration. I agree with these mindsets and think that they work together well.

That said, neither of them can be an excuse for putting out something bad. When I started on Ingot I create a minimal viable A/B testing algorithm assuming I’d get it right — statistically speaking later — once I had everything else working.

stained-glass-110788_1280This made sense to me, and once I had everything else working I sat down to write the code to do the math. I could have done it and I wrote a lot of it, but I realized that my approach was wrong. Not only that, I was adding it on top of some mistakes I made in the structure of my CRUD — separating price testing from content testing.

So, I spent “two days” throwing out half of the plugin and starting over. It was painful to throw out that much code — OK, I enjoyed it because Josh — but I’m glad that I corrected my mistakes before version 1.

There are somethings you can only do right, by doing them once in a way that is sub-optimal. Knowing when to throw out tons of code that works, has unit tests and documentation is hard. It’s not worth doing when it’s because you could have made the code cooler.

End-users don’t care about how fancy the code is, they care about results and they care if you can keep it working over time. Refactoring in order to meet your product design goals better, and to ensure your code will be more easily maintained over time is worth it.

Give It A Read

A yellow flower in out-stretched hands.I hope you learned something from this post. I’ve resisted the urge to put in big code examples, as I wanted to keep it abstract. That said, you should feel free to read the source code. I’m happy to discuss these decisions I made, or how you can integrate with Ingot. Leave a comment or tweet at me.

Tomorrow I’ll post my feelings on what the WordPress REST API means for plugin development moving forward. It’s obviously something I’ve thought a lot about and putting my own theories into practice was one of the most valuable parts of this whole experience.

How The WordPress REST API Changes WordPress Plugin Development


The Typical WordPress User

Over the last few years, I’ve provided a lot of support for WordPress users, so the low opinion many in our community have about the “typical WordPress user” is not shocking.  Having the privilege of attending WordCamp US and the WordPress community summit was a highlight of my year, and I had a great time but a few things about the experience were very disappointing.

The biggest disappointment was hearing so many people put down the intelligence of WordPress users.

There is a lot of disagreement on what a typical WordPress user is and what they can do. I witnessed and participated in some really serious disagreements about what a typical WordPress user can and can’t do. Whether they can use FTP, click 3 inputs in cPanel to update PHP, are a total moron, etc.

Too often this discussion becomes condescending towards the regular folks who make up the huge adoption numbers we see, and buy the products and services that make it possible for all of us to make a living.

This dismissive view of users is worse than the coffee was at WordCamp US. It’s fine to be a coffee snob, it’s not OK to look down at other for knowing less about WordPress and the related technologies than we do.

I’m OK with not budgeting for enough high-end coffee to keep 1800 of us awake. Remembering to bring my travel french press, which I did not, was my responsibility.

Coffee is a personal responsibility, but learning how to better know and empower our users — that is community responsibility. It’s worth the time, money and effort to do it right.

It’s an important discussion to have, but at the same time the argument has a logical flaw — the “typical WordPress user” is an undefinably large number of people. Even if we could define the total number of users, and calculate the mean technical ability set, the number of users within a reasonable range of that impossible to calculate value would be huge. The number who fall outside of it, but can’t be ignored, is also huge.

As much as I believe in the importance of good coffee, I believe that trying to define or design towards the typical user is the wrong approach.

Beyond Assumptions

I assume, based on the taste, that WordCamp Tampa Bay spent way more on coffee than most WordCamps do.

The life giving Kahwa Coffee at WordCamp Tampa was
The life giving Kahwa Coffee at WordCamp Tampa was excellent. 5 stars, strongly recommended.

It’s probably fair, though I haven’t done the research to prove it, that most “typical” WordPress users are unaware of the web browser console or how to use it to diagnose issues. As we move to more and more AJAX-driven processes, learning to use the console and network inspector to diagnose problems or at least give useful information in support requests is essential.

I am probably right that most users don’t know this skill. I’m only going based on my years of experience supporting WordPress users, not any data, when I make this assertion. My experience also shows that it is not a skill users can’t learn.

To argue that the typical WordPress user can’t learn this, or to upgrade PHP, or install a plugin is insulting.

WordPress is the single most empowering, and educational community, software, and experience of my life. I want that experience for everyone.

Not everyone will learn all of these skills. But trying to define the typical user, not the many user profiles, leads to an all or nothing approach. We end up with nothing useful.

It’s as wrong as drip coffee machines.

Moving Forward

Starting with better questions

Thinking that we can define a single user is insane. A better first question is how many user profiles should we be designing this software for? That question leads to a lot of other questions:

  1. How many profiles should be defined?
  2. What are those profiles?
  3. What relevant skills do typical users in those profiles know and not know?
  4. What relevant skills do users in each profile not know, but could be easily trained in?

Many people reading this hopefully have some thought on these questions. I’d love to hear them in the comments or on Twitter. But, I’d also like to hear how you would gather data to test these assumptions. Is it surveys, user testing, or something else?

I don’t know. It’s something I’m thinking a lot about. I’ll share more of my thoughts in the future, but right now, I think the first step is to rethink the problem. I lack the data to have an intelligent opinion. But helping to gather that data and put it to use is a very valuable thing that I want to work on and would encourage others to do.

Empathy and Empowerment Before Dismissiveness

We can’t help those we think are morons

Support Team Wapuu by Michelle Schulp
Support Team Wapuu by Michelle Schulp

The reality is a lot of people asking for help with WordPress do not know what they hell they are talking about. We could dismiss them as morons, or realize that the failing is our failing, not their failing.

We told them WordPress was easy. We told them our plugins, themes, services, etc. were intuitive to use. But clearly that wasn’t true for them. If that was true they wouldn’t be asking for help. They wouldn’t be frustrated. They wouldn’t be scared that they might not be able to complete the project they are working on. A project they might be getting paid for, or that their job may be riding on.

It’s easy to dismiss less experience users as noobs who are out of their element. It’s harder to empathize with when we ourselves didn’t know what the fuck we were doing with WordPress, or how bad we are at other things.

Some of us may feel good about tangible evidence of our superior technical knowledge.

In order to move WordPress forward, we must push past our assumptions, rely on data not anecdotal evidence, and stop ourselves from being dismissive. Once we do that, we can empower the many different types typical users.

Doing so will open us up to discovering the multitude of other solutions to the problems that scaling to 25% have brought us. Challenges that must be face before scaling past that.

It’s a wicked challenge and it sounds like a lot of fun to solve.

I Just Wandered Into This

There are a lot of reasons why my wife is awesome. Sharing my life with someone who is so driven and focused on her ambition inspires me. One of the many positive qualities she has is how well she takes a compliment.

It’s something I’m working on to learning to emulate. I’m getting a lot better at not replying to a denial or compliment with a self-deprecating joke, which used to be my default.

While I still have work to do, I think the way I worded the last paragraph, compared to how I express the thought it in my “mental draft” of this article — “it’s something I fucking suck at.” shows my progress.

WordCamp US and Community Summit BadgesAt WordCamp US I met a lot of people who I had helped through support, an article or one of my plugins. I had to work hard to take these compliments well.

When we deny compliments we are not only being rude to a person who is being incredibly kind to us, we are tearing ourselves down. Negating compliments is detrimental to self-confidence, self-respect and self-optimization.

It’s lying to yourself.

#realtalk I’m Awesome

See, I can do this!

I know I’m awesome and I don’t need other people to tell me that. But, it is great when they do:) While I have historically let the lack of self-confidence that compliment sabotaging grows out hold me back. It’s stopped me from asking for high enough pay, its stopped me from asking for help from others, it’s stopped me from finding the right financing for my business.

But, it hasn’t stopped me. Like the River Tam sticker on my computer says “No Power In The Verse Can Stop Me.”

Stickers on my laptopMy computer is also covered in stickers representing a small portion of what I helped build this year and a collection of Wapuus representing a small sample of the many WordCamps I’ve attended.

While I still have a few weeks left, I wanted to share some of the amazing things I’ve been lucky enough to be a part of this year by highlighting some of the publicly available work I have done.

But first let me tell you the thing I’m most proud of: every single item on this list is a collaborative effort. For those who keep asking me how I do so much, the simple answer is: David Cramer. I get to work with many other talented people, but I’m very lucky that I get to call one of the best plugin developers out there, someone whose form builder plugin blew me away with its awesomeness, my partner.

CalderaWP LogoThe CalderaWP sticker is at the top and it’s a pretty one that I’m very proud of. Our logo was designed by Lindsay Jo Crenshaw. It’s a fun logo and we strive to make plugins that are fun to use for the site manager and end user alike.

Since launching in February, we released 17 updates to Caldera Forms, and increased active installs from 1000 to over 10,000. We also released literally more Caldera Forms add-ons then I know about. Seriously, I need to check David’s GitHub for new ones I haven’t found yet. Some of my favorites are:

Caldera Connected Forms – Combines multiple forms into one big multi-page form. This allows you to create complex sequences of forms, with conditional logic on which parts to show based on user submission. It also tracks partial submissions and puts the results into one email and one database email.

Dwolla for Caldera Forms – This add-on was part of a GPL-powered partnership with GiveWP. It was also the project where I learned how Caldera Forms processors work.

Easy Pods, Easy Queries & Clarity for FacetWP. These three related plugins are really fun tools for creating custom search interfaces, as well as making working with complex WordPress as a  CMS projects easier. Expect to see more iteration and possibly integration of these tools in the future.

URL Builder — I think this was one of my better ideas, and was definitely one of the hardest challenges I through at David. It’s a great plugin I really believe in that is missing a few key features and should be marketed very differently. This is one I will probably be looking for a new partner or home for soon.

Ingot — The automated A/B testing system for WordPress. This is the plugin that is my current obsession right now. We’re currently in beta and hope to be launched within the next month or so. It’s the first of what I hope is many projects that are executed by CalderaWP and a separate group of partners. In this case, Christie Chrinos and Andy Larreategui are handling the business and marketing while I focus on development with help from Roy Sivan.

I met Christie and Andy at a startup weekend in Tallahassee. Since then I’ve had a great time working with these talented people, and been able to introduce them to the wonderful world of WordPress. It was very cool to see the community welcome these two newcomers at WordCamps Orlando, New York and US. It was also great to see Christie start contributing to the Spanish translation of WordPress during WordCamp US contributor day.

Someone else will have to count all of the articles I’ve written for Torque this year. The fact that I get paid to help myself learn while helping others is so incredibly special to me. I am super grateful to Marie Dodson for being a great editor for and everyone at WPEngine who makes what I do for Torque possible.

Torque’s Ultimate Guide to the WordPress REST APISpeaking of Torque and WPEngine I totally wrote a book! The book, on the WordPress REST API was a really special milestone for me. It’s been downloaded way more than a thousand times and I’ve gotten such great feedback on it. Major highlight of the year, I hope everyone who reads it makes something cool with the REST API and shares what they learned by doing so.

Speaking of the REST API, it’s so much fun to work with. I’m using it in Ingot to power our admin — a single page web app written in AngularJS — and in the front end to track the testing. I’ve also released REST API add-ons for SearchWP and WordPress SEO by Yoast.

In addition I worked on REST API integrations for GravityView and several clients including

I also made 16 commits to the REST API itself and contributed quite a bit to the docs. The REST API earned me one of my three “props” in WordPress 4.4.

Some of my favorite plugins I worked on for clients earlier in the year used custom APIs. These were fun to build, but REST API all the things moving forward.

The first of those plugins is Editus (formerly Lasso) by Aesop Interactive. I wrote a custom front-end AJAX API, and implemented. I also refactored their PHP to be more efficient and added new features. I can’t explain how much I love the process of architecting or re-factoring a WordPress plugin — #thatkindofnerd

I wrote a very similar API to handle live commenting in Epoch by Postmatic. This plugin was Jason from Postmatic’s vision, which I lead the development of and executed along with David, Jason and his developer Dylan Kuhn. Everytime I comment on WPTavern, it makes me smile to watch Epoch work.

Speaking of Postmatic, David and I also added three new features to Postmatic, MailChimp import, Subscribe2 comments reloaded import and the subscription optins. Also I got to know Jason, learn from watching him build Postmatic and from all of his advice he gives us on Caldera Forms.

On the topic of awesome clients that are more than just clients, Matt Cromwell and Devin Walker from WordImpress are just great people. They are encouraging, full of great business advice, give great feedback on our plugins, as well as being vocal supporters and users of Caldera Forms. We also worked on two plugins for them this year.

While I moved away from Pods this year, I still contributed to the project. We launched Friends of Pods, a program to help support Pods financially and I just wrapped up a really cool REST API integration for Pods 2.6.

Even though Pods is no longer my main thing, I always want to be a part of it. Pods was my first WordPress team and I would not be where I am today without support, encouragement, mentorship and friendship I have received from Scott Kingsley Clark, Phil Lewis and Jim True. The Pods sticker on my computer is one of the fanciest stickers on my computer and one of the ones closest to my heart.

WordCamps and Community

I’ve been everywhere…

I have an article coming up on Torque about my thought on attending 8 WordCamps in a year. I just want to say how much I love these events and how special it is to be able to speak at so many of them.

WordCamps are an affirmation and celebration of this community. It’s an unimaginably supportive community. This was my first year selling WordPress products. Getting advice and encouragement from Ben Fox, Nick Haskins, Matt Cromwell, Jason Lemieux , Daniel Espinoza, Vova Feldman, Asif Rahman, Naomi Bush, James Laws, Corey Miller has been invaluable. Reviving these gifts of knowledge is humbling and its. a challenge to me to pay it forward as much as I can go help this community grow together.

Enough About Me

Y’all are awesome.

wordpress-logo-simplified-rgbI’ve been talking about myself way more in this article than I’m used to. Not going to lie, it makes me uncomfortable. But, I know none of it would be possible without everyone who reads my articles, uses my plugins, gives me great advice and encouragement.

This year was also my first time attending the WordPress community summit, which was a special experience. It’s a true honor to be invited to the event. Community Summit is a private, confidential event so I can’t share too much about it. But, to be with 150 leaders of my industry passionately debating how to best move it forward is an unparalleled privileged.

Honestly, this whole thing that I get to do is a privilege. I’m so excited to build on the groundwork that we — David, Christie, Andy, Roy and everyone else I work with and I have built. It’s what’s going to make it possible for all of us, everyone I’ve mentioned here and more grow together in 2016.

It sounds like so much fun.


WordCamp Orlando: 5 Major Events In The Life Of A WordPress Request

I’m presenting at WordCamp Orlando today on major events in the life cycle of a request to the front-end of WordPress. The goal of this talk is to help you understand how we get from this:

Screenshot of WordPress' index.php
This is index.php, where every WordPress request begins.

To this, or really any page on your site:
Screenshot of Twenty Fifteen

But what I really want to encourage people to do is to get in the habit of reading the source
Read The Source Luke meme

Helpful Links


Learn The WordPress REST API With Me

API Wapuu by Michelle Schulp.
API Wapuu by Michelle Schulp.

I’ve had so much fun teaching myself the WordPress REST API for the last year or so. Part of what has made the experience so great is sharing what I’ve learned a long the way — tutorials, WordCamp talks, Podcast appearances, a free ebook.

I can’t decide what I love more — using the REST API to build custom APIs the WordPress way or sharing what I’ve learned. So, I’ll just keep doing both.

That’s why I’m happy to announce I’m working on a four part video course, teaching you how to use the WordPress REST API.

The REST API Is The Future Of WordPress

Actually, it is already in use by those doing the coolest stuff with WordPress.

Infographic on how awesome the WordPress REST API isWordPress just hit 25% market share among content management systems. That’s awesome, the more growth in our industry the more potential customers or clients there are for people like you and me who offer WordPress services and products. We know that there are a lot of negative opinions about WordPress out there. Some of them are fair, some of them are not.

The more times we can exceed the pre-conceived opinions about WordPress, deliver more “You can do that with WordPress?” moments, the more our industry will grow. I want you to be the one to deliver that “wow” moment to your clients. I want you to be able to give more to your clients than they expect from a WordPress site. Don’t forget to raise your rates 🙂

But Wait There Is More!

And more!!

The course will be available in December 2015. But if you sign up today you will get a special discount. Don’t delay — once the course is ready for download, the price goes back up.

Want to learn the REST API one on one with me? I’ve got a special bundle that includes the course and a one on one consult call via Skype or Hangouts.

Introducing Ingot: Convert More, Do Less

Recently I was setting up a MailChimp campaign and the MailChimp interface asked me if I wanted to run an A/B test. Of course I do, MailChimp. You’ve got to A/B test everything. I’ve been on the internet, I know that to be the truth.

So, I started setting up an A/B test for subject line, but then it occurred to me that I already did that. I wasn’t sure so I looked through my campaigns and found I was right. So then I set up another test of course, because thou shalt A/B test all the things. Then it came time to enter my from line, so I had to look up what had one last time.

This is why I never A/B test and I hardly ever read my Google Analytics — I don’t have time for that. Read it, analyze it, apply what I’ve learned on my site and then start the testing over again. I’m already doing too many things, I want to set up all of the different options and let my site figure out over time what converts best and use that.

So, speaking of doing too many things at once, I wrote that plugin.

Meet Ingot


Ingot LogoIngot is the “do less, convert more” tool that anyone who wants to make more sales, get more downloads, increase their email list subscribers needs without becoming an A/B testing expert, needs. It gives you a simple UI to set up a series of tests, and works to find the one that converts best, overall, based on browser type (mobile, desktop, etc) and refer.

For example, enter 7 options for a call to action button and Ingot will find the best one over time. On the other hand, if you are running an eCommerce site and want to find out what gives you the most revenue; lowering your prices 5%, raising them 10%, or maybe you raise only your highest price variant. It’s never been easier with Ingot.

We’re starting off with a WordPress plugin. Don’t worry, I’ve been paying attention at WordCamps and we’re already planning the WordPress-powered SASS service so you can Ingot on any website. Thank you WordPress REST API.

By the way notice the “we” in the above paragraph? My new year’s resolution for 2015 was to stop working alone. It’s the only new year’s resolution I ever took seriously, and it’s been the most fun. From CalderaWP to this new team, not working alone is a great thing.

Meet Team Ingot

These are new friends.

Earlier this year, in a wonderful spell of “Josh get out of the house, network, meet people!” I attended Tallahassee Startup Weekend. I ended up on a ten person team that proposed an social network for entrepreneurs. I know, silly idea, though maybe there is some room for innovation. But it was a good experience.

Afterwards, a few of us refined it, made an MVP, tested it a bit and confirmed the suspicion that it wasn’t a great. That’s OK. We were learning to work together and building a team. Ideas are cheap, teams are hard.

We’re down to three of us including me. The two partners I have for Ingot are awesome. If you’re reading this you’re likely one of the “WordPress people” in my life. So you probably don’t know my new friends, but I hope to introduce them to you at an upcoming WordCamp.

Andy Larreategui is doing our marketing and sales. He is a senior in Political Science at Florida State University. He’s the kind of guy you call when you need 1000 twitter followers real quick.

Christie Chirinos is driving the bus as our CEO. She has a B.S. & M.B.A. in Management from Florida State University. She currently works at the Community Animator at the Centre for Social Innovation in New York City.

Josh, What About All Your Other Things?

What about them?

CalderaWP isn’t going anywhere. Part of why Ingot is a thing is so I could get this idea out of my head without having to sell another product without being the operations, sales, marketing, etc. person for the company. That’s what I do in CalderaWP, David is the lead developer. It’s nice to be doing both in different contexts

And yes, I do a lot of stuff. Too much stuff? I don’t know, but I’m having fun finding out, and working on all these challenging new projects along the way.

Where Is Ingot Now?

It’s about to be on the sites of our beta testers.

Ingot is in beta mode. We’d love to show it to you and learn what else you think it should do.

If you are at WordCamp New York City this weekend, find me. I’ll introduce you to Christie and we’ll give you a demo. If you are headed to WordCamp Orlando in two weeks, find me. I’ll introduce you to Andy and we’ll give you a demo.

You can also go to our website to learn more and schedule a demo.



On Persuasive Writing, Narratives & When To Call The WordMaid

Being told no sucks.

No matter how hard I orient myself around the perspective that being wrong is the best learning experience, being told no one wants what I am trying to sell is hard.

I’ve been thinking a lot about conversion rates recently. Not just because I sell things online,  but because I have two upcoming product announcements that are about boosting conversion rates.

You know, the awesome thing about conversion rates is we talk about winning 10% of the time. Not losing 90% of the time. If your target conversion rate it is 10% and you hit that you have a “the glass is full enough for us to drink” outlook, not a “the glass is quantifiably speaking, less than half full” view of the world.Yesterday, I shared a draft of a post I’m working on about one of those products with my team and they called it “good persuasive writing.” I hadn’t thought of it as persuasive writing, I just did what I do — write a story about something I’m working on.

I’m not telling you what these two new products are, yet. I’m taking you along for a narrative journey to them.

If You Need WordPress Sales Copy Done Right, Talk To Lisa

Social proof works, friends.

When I started CalderaWP I knew I’d need to do a lot of writing of sales copy. A lot really, since we have so many plugins. You have no idea. Seriously, go to our plugins page, look at all those plugins, realize that there are a ton more we haven’t QAed yet.

I wasn’t worried. I think I’m pretty good at writing about WordPress. People keep telling me I am. So I wrote a bunch of sales copy that I thought was simple and easy to understand. People started telling me that it was “to techy” and didn’t make the benefits clear.This upset me, because I thought I had made it all simple, clear and not too technical. I love doing it all myself, but I also know the value of building teams and outsourcing when needed. So I hired Lisa Gibson of to fix some of our sales copy.

Why her? Andrew Munro of AffiliateWP and Easy Digital Downloads endorses her on her site. That’s about as targeted of social proof as you can get. I needed someone to improve the sales copy for products in a similar niche to what Andrew does, and I’m selling them on a site powered by Easy Digital Downloads that uses one of Andrew’s themes.

Go niche or go home.

Did I mention she delivered, and delivered really quality work? Seriously, she made the pages for Caldera Forms, Easy Queries and URL Builder so much more clear and simple. And guess what? They convert better now.

Start With The Other Why

It’s about the journey, not the destination.

Map of Middle Earth
Map of Middle Earth (via WikiCommons)
Map of Middle Earth (via WikiCommons)

So I realized that I needed help making my sales copy clear, simple and easy to understand, so I hired Lisa to work her editing magic. It made sense and you should to.

But, sales pages are not your only sales copy. When someone gets to a sales page, they are looking for the details. Why do I need it? How does it do that? What does it cost? Your sales copy needs to give them that and make it clear why.But how do you get them there. You engage them with a story.I’ve written before on how I work to craft my WordPress tutorials as a narrative journey in which build empathy with the reader. I do it to empower them to go on a journey where they believe they can do the thing I’m explaining. It’s important since explanation is worthless if the person you’re explaining to doesn’t believe they can accomplish the goal they have set out to achieve.

Simon Sinek’s “Start With Why” has become a sales mantra. Start with why someone needs your product, or to believe in your cause, why it reinforces their notion of self. Not what it is or even worse how it works.But you can step back a step, and take people on the journey off why you’re making a product, why you’re championing a cause.

I Think Y’all Like Me

If not, be nice and don’t say anything

Since I first wandered randomly into the WordPress world it’s been amazing how welcoming I’ve felt. Sure, I get socially awkward, and convinced I’m a fraud and no one likes me as much as the next person sitting alone in his room letting impostor syndrome consume them.

But y’all keep sharing my articles, downloading my book (1400+ times,) inviting me to speak at WordCamps (8 by years end,) downloading Caldera Forms (we’ve pentadrupled the active install count since launching CalderaWP) and otherwise making me feel welcomed and appreciated.That’s super awesome.Thing is y’all inspire me more than you know.

So why wouldn’t I share the journey that is taking me to all these fun things I get to be a part of making?

Extending The REST API Talk

My fall 2015 WordCamp talk is on extending the WordPress REST API. I love doing tweaky server-side PHP development, so I fell in love with the REST API, and even more with the extending it. I’m excited to be giving this talk a few times and hope to have video of it up soon.

You can see my slides, video from the talkm and a helpful list of links below.

By the way, did I mention I wrote a book on the REST API? Well I did, and it’s both awesome and free — thanks to the good people at Torque and WPEngine. You can down download it here.

In my talk I give an introduction to extending the REST API by modifying the default responses and creating your own endpoints. If you’re like me, and learn by reading code, I recommend checking out these two plugins I wrote:

  • SEO REST API Fields This plugin exposes SEO fields for WordPress SEO by Yoast in post endpoints, and allows for updating them along with the post data.
  • SearchWP API This plugin adds a custom endpoint for doing advanced queries, powered by SearchWP — an amazing WordPress search plugin — using the REST API.

I wrote a post a few weeks ago on the topic of extending the REST API, with more links to docs, and articles I wrote for Torque. Be sure to check that out.


On Confidence

I once told a therapist that I felt like my lack of confidence in my own abilities was holding me back. He told me that I couldn’t have confidence in my abilities until I achieved something. Despite the fact that I thought that therapist was full of it, I still bought into that BS he fed me that day for years.

Everything I’ve been able to accomplish, from going back to school and getting two degrees and everything I’ve done in WordPress has come from me suspending my disbelief in my self.

Over time I found the strength to go out on a limb and trust myself that if I tried new things and believed in myself  I could get good at new things. If I hadn’t done that, I’d still be stuck in the same trap.

What my therapist told me, that I needed to accomplish something before I could have confidence was a catch-22. Thing is there is a grain of truth to what he said.

You can only get so far on “I think I can.” You have to build on success.

Pods Frontier Auto Template BannerThis week, we merged a plugin I wrote for Pods — Pods Frontier Auto Templates — into Pods itself. That plugin was not my first WordPress plugin, but it was the first WordPress plugin that worked and people actually used.

When I presented the idea as a feature for Pods, I’m not sure if Scott had me make it as a plugin because he didn’t see the need for it in Pods, or if he didn’t think I was ready to be doing development in Pods itself. The latter would have been a very fair assessment at the time.

Either way, I was determined so I made it as an add-on plugin and source material for tutorials. And it worked. It stopped people from asking for what they saw as a missing feature in Pods, and we had almost no bugs with it.

When I started working on merging it into Pods itself, I was so overcome with emotion I actually had to stop and come back to it. Everything I’m doing now with CalderaWP, with client work, etc. — when I say “yah I can do that” whether I currently know how or not, that’s building off of the confidence I got from that plugin. What I got from getting positive feedback on it, from it not needing a lot of improvements or bug fixes past the first version, from seeing it pass 1000 downloads, etc.

This is one of the reasons I tell everyone who is getting into WordPress development or any type of programing that they have to find an open source project to get involved in. When you’re starting out, you need support and guidance from more experienced developers. I got that and more from Scott and Phil. You also need to be able to find a small thing you can do, inside of the larger thing, to carve out, improve and feel awesome about doing it.

Tell People They Are Awesome

You are awesome.

The WordPress ecosystem is full of people who are trying something for the first time, or the forty-second time and have no idea if anyone appreciates what they are doing, finds it useful, or is using it. When you try out a new plugin, theme or service and you like it: say it. Call the author out on Twitter, leave a review, write a blog post… whatever — just say “you’re awesome.”

You never know what telling someone you appreciate what they created will do for them or who will see what you said and try it out.

And yes, this applies way beyond our little WordPress world. The internet can be a cold, impersonal and cynical little place. A simple “you made something awesome” goes a long way to change that for someone, so don’t forget to say it.