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.
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.
I 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.
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
Too 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.
But, 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.
Older 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.