Why you should unit test WordPress plugins

Probably the single biggest regret that I have in my development career thus far is that I didn’t start writing unit tests for my code at a earlier stage. I was kind of a late adopter to testing and only really started testing my code properly with unit and integration tests in the last 4 years.

If I had started writing tests earlier, I know for sure that I would not only have saved myself a ton of time, but also have become a better developer faster. That’s because testing has changed the way that I write code, for the better.

The biggest argument that is used against testing is that it takes too much time to write tests. And it’s hard to argue against the fact that is does add overhead to your development. But the amount of time that you’ll save in the long run by having a decent test suite far outweighs the initial cost of writing the tests.

It’s hard to convince developers who have never actually felt the real benefit of a good test suite of the long term benefits of testing. If you’ve never written tests before or worked with a codebase that is tested, then bear with me as I try my best to explain why you should unit test your own WordPress plugins.

3 reasons why you should unit test WordPress plugins

There are 3 reasons why I continue to write tests for my code.

Unit tests eliminate existing and future bugs

By writing unit tests, you are both testing your code in it’s current state and making sure that it does what it is supposed to do. And you’re also writing a test that can be used over and over again to make sure that your code is still doing what it is supposed to do as you add more functionality.

I recently took a piece of code in a WordPress plugin that was not tested, wrote a test for it and discovered that it was actually not doing what it was supposed to. If that code got shipped in it’s pre-test ready state, it would have probably resulted in support tickets and frustrated customers. Writing tests can be a great way to debug code that doesn’t already have tests.

Unit tests document your code

Before I look at a piece of code, I like to check if there are tests and if so, read through them as they usually tell you exactly what the code is doing and shouldn’t be doing.

By writing tests, you’re providing documentation for other developers who may work on the same codebase. Never mind other developers, have you ever gone back to a piece of code that you’ve written and been confused as to what is going on? I have, often.

Good tests are usually so much more effective at explaining the ins and outs of your code than badly written documentation or incomplete code comments.

Unit tests make refactoring code much easier

How many times have you refactored code, only to realise later on that your refactor broke some related functionality in your plugin? Perhaps the code that you refactored was not just written for the feature you were refactoring, but for other features too and you didn’t realise it. This happens often if you’re not writing tests.

With decent test coverage, you’ll know exactly if a piece of code you’ve written has broken some other part of your code because the tests will fail.

Are these good enough reasons to start unit testing your plugin?

I think so. And that is because the 3 reasons I listed above will do two things for you:

  1. Save you time in the long run. You’ll write more bug free code which will reduce support requests and debugging headaches. You will also not have to explain over and over again how your code works both to yourself and others.
  2. Make you a better developer. You will be able to push code with confidence knowing that you’re not breaking your plugin. You will also find that writing unit tests forces you to use good programming patterns and design.

If you’re still not convinced that tests are beneficial, all you need to do is work on a codebase which has decent test coverage and feel it for yourself. I know that I am a better developer for it.

Automate your WordPress development workflow

As you get older three things happen. The first is your memory goes, and I can’t remember the other two. – Sir Norman Wisdom

One of the keys to being a productive WordPress developer is to automate your WordPress development workflow. That is, wherever possible let tools and scripts do your work for you. The less work that you have to do and the fewer processes that you need to remember to follow, the better a WordPress developer you will be.

In a perfect world, we’d all be infallible and code would run bug free on the first execution. As we know, this world is far from perfect and as humans we are definitely prone to making mistakes as we code.

Automating your WordPress development workflow can bring your closer to being like that infallible developer we’d all love to be.

What to automate in your WordPress development workflow

There are a few crucial things that you need to automate right away if you have not already done so. They are:

  • Development environment. If you’re having to manually create a development environment every time you start a new project, reformat your machine or have someone else work with you on a project, then you really need get setup with a scripted development environment.
  • Code standard and listing checks. You should be automating the checking of your code against the WordPress Coding Standards. I’ve discussed why this is important before. Standards and linting checks should preferably be done as you write your code, but as a last resort, before each code commit.
  • Code completion. You will save yourself a ton of time by using a code completion tool that understands the WordPress codebase as well as the code you’ve written and can autocomplete based on that knowledge.
  • Snippets. Have a decent library of repeatable snippets of common WordPress code that you use often. These snippets should also include those pesky function calls which you forget the implementation details of and usually end up having to reference the WordPress documentation to figure out.
  • Boilerplates. Similar to snippets but on a larger scale, boilerplates save you from having to write structural code for your projects and let you skip straight to the important pieces such as the functionality. At the very least you should have a theme and plugin boilerplate that you reference when starting a new project.

There are some additional areas where you can look to setup automation. They include:

  • Deployment. Are you still FTP’ing files up to your server? You can automate the deployment of your code from your local development environment to live with a single command.
  • Unit test execution. Unit tests are a vital component to a maintainable project. I love writing tests. If you’ve got tests, automate the running of those tests either in your IDE or on commit.
  • Scripts for doing repetitive tasks. If you find yourself repetitively typing the same few commands in to a terminal to get something done, then you should write a shell/bash script to run those commands using a single command. A good example would be your Git workflow.

How to automate your WordPress development workflow

Luckily, WordPress has a thriving development ecosystem and there are great tools for automating your WordPress development. Here are some of my favourites:

  • VVV – A scripted WordPress development environment. Enough said 🙂 Also be sure to check out VV for creating sites on top of VVV. I’ve also written an article on setting up VVV with videos.
  • WP-Dev-Lib – This is a set of scripts that can be implemented on top of any WordPress project. They help automate the linting, running of tests and deployment of WordPress themes and plugins. See my article on applying WordPress coding standards for a video on setting up WP-Dev-Lib.
  • PHPStorm – I know that IDEs are not everyone’s cup of team and if you’re one of those developers who doesn’t like an IDE, I would urge you just to try out PHPStorm for a week and see what it can do for you. In terms of automation there are snippets (Live Templates), Emmet, the best WordPress autocomplete you will find anywhere and many more features that make your WordPress development bliss.
  • TextExpander – I use TextExapander to save code snippets that can be used inside PHPStorm or anywhere else really.
  • WP-Foo-Bar – I’m biased here since this is built by XWP and I work there of course, but choose any standards based WordPress plugin boilerplate and use it religiously.

That should be enough to get you setup with a well automated WordPress development workflow.

The sheer amount of tools and scripts available for automation may seem overwhelming. I would suggest that you start small but implementing a single item. Once you’ve got that down, move on to the next tool or script.

Before long you will have eliminated a lot of the grunt work out of your workflow and you will be writing cleaner and more reliable code.

The pursuit of WordPress development mastery

For a large part of my career in web development, especially in the early days, I’ve been guilty of trying to do too many things at once. I’ve known deep down that focus is a good thing, but had a fear that by narrowing down my development focus to one or two things, that my skills would become irrelevant.

I think that’s a fair concern, especially today. Things in the web development space evolve quickly!

On the other had the longer that my career has gone on, the more I’ve realised that if I want to produce my best work, I need to get really specific about what I do.

This clearly conflicts with the fear of becoming irrelevant. How do you balance being an expert at a few things and staying relevant with the web development industry?

I’m still figuring out the answer to that but at the end of last year I bit the bullet and focused (some would say niched) down entirely on WordPress development.

It was hard to do at first. I continually had feelings of wanting to be more than just a “WordPress developer”. It also mean’t that I had to give up a lot of stuff that I was doing that was outside the scope of WordPress development. I even threw away hundreds of pieces of content on this blog as it was not related to WordPress development.

WordPress development mastery

In order to achieve WordPress development mastery, I needed to be totally focused on only WordPress development. Not just in my day to day work, but also in the brand that I project to the outside world.

It’s been a few months now in my pursuit of mastery, and I can positively say that the results of my efforts have paid off in a number of different ways…

  • I landed a dream remote working WordPress development job
  • I’ve formed relationships with a number of the top developers in the industry
  • I’ve become a better developer by focusing on fewer things and doing those few things really well
  • There is no overwhelm of trying to do too much
  • Even though I turn them down, there has been a number of good work opportunities come my way

How to achieve WordPress development mastery

Achieving mastery in anything really just requires hard and focused work. It means eliminating the unnecessary and focusing on the things that will move you forward in what you’re wanting to achieve.

For WordPress specifically, here are some actionable items that you can do in a quest for mastery.

  • Read and learn as much as you can (books, courses, communities, forums, blogs)
  • Write WordPress code as often as you can, even if it doesn’t pay you to do so!
  • Build your online brand (the easiest way to do this is to start a blog)
  • Contribute to the Core and learn from code already in the Core
  • Reach out and form relationships with others in the WordPress space (read: go to WordCamps)

Take a single action each day from the above list and apply it. Within 3 months you will become a better WordPress developer and before long, start to feel like a real master of the craft.

When I first got started I made some real rookie mistakes due to lack of experience, but the more I execute on the above actionable items, the better I get and less mistakes I make. With each day that passes, I’m becoming a stronger WordPress developer.

It also really helps to find mentors or leaders in the community to guide you.

Focusing down even more

The next step for me in my journey to achieve WordPress development mastery is to focus down even further. This again is a scary thought but an important one. Like I say, I’ve learned that the more laser focused I am with my work, the better the work is that I produce.

The way to focus down further for me would be to focus on specific pieces of WordPress development and only execute on those. Slowly but surely I am figuring out what those pieces are.

As far as becoming irrelevant goes, the fear that I had initially has mostly disappeared. The thing is, I’ve come to know myself as a person who can adapt easily. If WordPress does eventually wash out, I know that I can adapt my skills to something else. For instance, I’m now doing a lot more Javascript work that is easily transferable to other industries and projects.

Focusing down on WordPress development mastery is a great choice as it exposes you to some of the best development languages, tools and practices. Those are transferable skills that can be used elsewhere.

Lastly, if you’re struggling with focusing down like I did initially, then have a read (or listen) of the book called Essentialism by Greg McKeown. It’s an excellent resource that helped me work through some of the fears and doubts I had. It also will help you figure out what you should eliminate out of your already far too busy life.

 

Why I chose a managed WordPress hosting solution over a VPS

For a very, very long time now I’ve been running my WordPress websites on a cloud based virtual server. I’ve been through many different providers including the likes of Linode, AWS and most recently DigitalOcean. It’d be fair to say that overall, the experience of each provider was good, if not great.

Recently however, I decided to move my sites to a managed WordPress hosting solution. The migration is not complete just yet, but it will be by the end of this month.

Running your own cloud based server has many different advantages over a managed solution. Apart from the obvious (complete control) it also enables things like…

  • Allows you to run your own deployments
  • Do more than just host websites, you can even host your own mail service
  • Access to private cloud storage
  • Host your own private code repositories
  • And lots more

You also get to play system admin and very quickly learn how to manage your own server which is a useful skill to have as a developer.

By moving from a virtual server where I had pretty much carte blanche over what I could do on the server, to a managed WordPress hosting solution, I am giving up a whole lot of control. While it may sound like a lot to give up, it is in fact the exact reason why I am moving to managed WordPress hosting.

When managing a cloud based virtual server goes wrong

It’s awesome to have complete control over your server… until things start to go wrong.

While I haven’t had any really major incidents (i.e. data loss), there have been multiple times where I’ve got alerts during the middle of the night because my server went down. In the past I’ve had to spend countless late night hours working to get my server back up after it crashed.

Now it may very well sound like a server crashing during the middle of the night is caused by some incorrect configuration. Maybe due to an increase in load that the server wasn’t setup to handle. Perhaps caching gone wrong. All things that a competent system administer should be able to avoid. And if you are thinking that, you are exactly right.

Many of the issues that I experienced were due to my lack of system administration knowledge. While I feel that I can scale code pretty well, I don’t know very much about scaling hardware/servers.

Why I chose managed WordPress hosting

So the the real point here is that I’m not a system administrator, I’m a developer. I know the basics of system administration and can keep a small, simple server running for a long period of time. But it’s not what I am focused on and definitely not what I am a master of.

I’m far better off spending my time building WordPress plugins and applications and letting someone else manage my hosting. Someone who is passionate and an expert at it.

The older I’ve grown the more I’ve come to realise that I can’t do it all. It’s far better for me to focus on getting great at a few things and let someone else, who is an master at things that I am not, do what they do best.

This is definitely not always practical but the more tasks I can outsource, the more time I have to become a master of the things that I want to get good at.

For me, WordPress hosting is exactly one of the areas where I’m better off letting someone else do the hard yards.

Applying WordPress Coding Standards

I’ve always found myself to be slightly OCD when it comes to writing code. Ok, maybe not just when writing code, I insist that my cars digital volume display sits on an even number at all times…

Anyway, extra spaces, lack of new lines and proper white spacing in a codebase really bugs me to no end. And even though I always try my best to make sure my code is squeaky clean, the truth is that I’ve often shipped code with the very annoyances that irritate me the most.

That’s also not to mention shipping code with other issues such as incorrect sanitisation, no docblock comments, forms without nonce values etc. We’re all human and prone to making mistakes in our code every now and then.

Mistakes can be costly though and especially as we work on WordPress and open source software, it’s even more vital that we take care and automate the checking of our code style and security – or as I’ll refer to them from now on, our WordPress coding standards.

Why you need to apply WordPress coding standards to your codebase

There are many different reasons for being really strict when it comes writing WordPress code and implementing coding standards. Let’s look at some of them.

  • Avoid your codebase becoming a big mess. If there are no standards applied to your code, then it can quickly become a big mess. Especially when there is more than 1 developer working on the same code. Each developer has his/her own quirks and way of doing things. If they’re not kept in check, things escalate fast and code becomes messy.
  • Follows industry best practices. By adopting an industry best practice, your code is written in the same way and the right way. Just like all the other top plugins, themes and applications. This is clearly beneficial to the community as a whole as everyone is adopting the same practices when writing code.
  • Makes sure your code is secure. Code standards should include checks to make sure that the code is securely written. It’s easy to forget a nonce on a form or to output a variable that is not escaped. WordPress coding standards define how to write secure code and should be strictly enforced.
  • Documented code is much easier to read and understand. Your code standards should enforce documentation of classes, methods, variables etc. Having documented code is again a win for everyone as the code becomes much clearer when trying to add to it or refactor it.

Why you should automatically check your WordPress coding standards

As we know, WordPress has a number of defined coding standards that have been laid out and enforced on core development. Unfortunately when it comes to themes and plugins, it is not as easy to enforce these standards since the control lies with the theme plugin or author.

Many of the better plugins and themes however have adopted these coding standards.

Like mentioned earlier on in this piece, it can be easy to simply forget to follow a standard. This might be as small as forgetting a space before a closing bracket or as dangerous as outputting non-escaped text.

Worst yet, it’s a pain having to implement standards and always having to remember to follow them. Never mind having to tell a colleague that what they’ve coded is incorrect.

The simple solution is to automate.

You need to automate the checking of your coding standards. Doing so will eliminate the need to always be thinking about it (although after a while it really becomes second nature), will save you the pain of having to tell your colleagues they coded something wrong (the build process will do that for you) and best of all, catch any missed security issues that may have been introduced.

Importantly though, automated checking of code standards will not catch everything and it’s still important to make sure you’re coding diligently.

How to implement automated checking of WordPress code standards

The really good news is that there are a number of open source projects written to automate the checking of WordPress coding standards. There are two specific projects that you should initially look at.

The first is the WPCS project. The WordPress Coding Standards project is a whole set of PHPCS rules to make sure your code written for WordPress follows the outlined conventions.

To get you started with WPCS, here is a video I’ve recorded to help you get setup on your own project.

Then the next project that is worth looking at is WP-Dev-Lib. This is a whole package of tools to facilitate the development of WordPress themes, plugins and sites.

WP-Dev-Lib includes the WPCS project mentioned above but goes a step further by including tools and scripts for unit testing, deployment and additional standards checking.

Here is a video which goes through how to setup WP-Dev-Lib.

These videos will give you a good head start into making sure your code is developed the right way. It’ll reduce the amount of work needed to make sure of that and let you focus on writing your best code.

Virtualize your WordPress development environment with VVV

WordPress development tools and environments have come a long way since I started working with WordPress in 2005. Back then I mostly coded using notepad and tested my changes in a live environment.

As time went on, I quickly learned about WAMP and later on XAMPP. They became my tools of choice for managing my local development environment. They worked great and testing code was a lot easier than it had ever been.

I then left the web development space in 2012 and started working in the payments industry. I had a good three year run in that industry but knew deep down that my calling was web development. Specifically WordPress development.

So when I returned full time to WordPress development, it quickly became apparent that the tooling had advanced rapidly. There were now excellent new tools for managing WordPress development environments.

With the rise in popularity of Vagrant and virtualization across many different development platforms, it only made sense that the WordPress community adopted these kinds of tools too.

There are many advantages to virtualizing your development environment.

Advantages of a virtualized development environment

  • Your development environment is scripted and automated. There is very little that needs to be done to setup your environment other than running a vagrant up command.
  • It’s now also portable. You can simply package up your environment and give it to a coworker or client who can then run it on their machine without hassle.
  • Since your environment is a virtual machine, it’s cross platform. Tools like VirtualBox work great across multiple different operating systems. There are no specific configs based on the operating system that you’re working on.
  • You can closely replicate your live environment. Your local development environment can run the same operating system, configurations and server as your live environment.

There are of course some downsides to virtualization as well. Depending on how many virtual machines you’re running and the memory allocated, they can be a bit resource intensive. It also takes time for the provisioning to happen since you’re basically downloading and installing a whole new machine.

Those are the tradeoffs but in my mind they’re minor compared to what you getting out of virtualization.

VVV – Varying Vagrant Vagrants

There are a number of different tools currently available for setting up a virtualized WordPress environment. My personal favourite is Varying Vagrant Vagrants. That said, I have not yet had the time to explore many of the other options available. They include Wocker, VagrantPress, HGV, and more.

VVV seems to be the most widely used of what’s available and the community support is pretty good. I’ve rarely run in to any issues with it.

If you’re still using WAMP, MAMP or XAMPP or maybe even running a web service directly on your development machine, then I would encourage you to try out VVV.

To get you started I’ve previously recorded a video on getting started with VVV for WordPress development. After going through it you should have a good grasp of VVV and be able to start using it immediately.

Setting up VVV for WordPress development

Additional resources and videos

Additionally, check out my article on PHPStorm for WordPress development which includes a video on integrating VVV into PHPStorm.

Lastly, here is another video on my 5 top Vagrant commands that you need to know.

 

WordPress plugins as features

One thing I’ve struggled with in the past when creating WordPress sites, is where to draw the line between the code that should be added to a WordPress theme and what should go into WordPress plugins. It’s usually not an issue on a smaller sites such as my own site, but when you start developing larger and more complex sites, things can get a bit hairy.

I’ve worked on projects where we built everything into the theme. I’ve also worked on the complete opposite where almost the entire site was created using plugins. Naturally, the majority of the projects that I’ve worked on have gone for a hybrid approach of using both.

The hybrid approach is the one that causes the most confusion, because the line between what goes where doesn’t really exist and constantly changes.

Although all approaches have their merits, these days I feel quite strongly about creating modular plugins rather than sticking everything in the theme or going hybrid. There are a number of reasons for this that we will get in to shortly. Again, this doesn’t really apply to smaller sites but bigger feature rich websites.

The relationship between features and functionality

Traditionally when we think of WordPress plugins, we think of them as enablers which add additional functionality to WordPress. They extend WordPress. These plugins usually serve a purpose behind the scenes. This added functionality in turn can become features if it’s integrated into your theme.

I mostly like to think of plugins (especially the majority of plugins in the repository) as how you are able to do things (i.e. your functionality) where as features are the result of implementing that functionality and are what the user is able to do.

So, it’s quite clear that when building something that is going to extend WordPress, it should always be created in a plugin. The grey area here is the code that does not extend WordPress, but rather turns the available functionality provided by WordPress and 3rd party plugins in to features that your users love.

WordPress plugins as features

Now that we’ve cleared up what features are (the what and not the how), how should we implement them? Plugins, themes, hybrid? Like I mentioned above, I feel after working on many different WordPress projects, that plugins are the way to go. Why?

  • Your website/application becomes modular. Every little piece of your site is broken down in to features which you can easily turn on and off. You simply just activate or deactivate the plugin.
  • It forces decoupling of your code. Coupled code is usually bad. By writing your site features as individual modular plugins, it forces you to write code that is independent of any other feature that you’ve built out in it’s own plugin. While it’s possible to couple two modular plugins, it’s far more difficult than if you where to have all your code in a single theme or plugin.
  • It’s much easier to maintain features. Because each plugin usually serves around 1 or 2 features there is far less code to look through when debugging. It’s also easy to find something that you’re looking for in your codebase because you will know which feature it is part of. Refactoring is a breeze!
  • Another unusual side benefit is that I’ve found that it helps me define my classes in my code. Because each plugin has laser focus on it’s purpose, it’s usually quite easy to apply meaningful names to your classes and methods.

What could go wrong?

While all the above sounds great, there are some drawbacks to the approach too.

  • If you’re not careful and you get too granular with your feature plugins, you could end up with hundreds of plugins. This becomes a bit of a headache to manage. There is a fine balance between too much and too little modularity. It takes time to get a feel for the right amount.
  • Since your theme basically becomes your controller, it can end up with a lot of if/else to check if a plugin is enabled or not. Wherever possible try to make sure modular plugins use actions and filters. You should be doing this already in any case.

The purpose of the theme

So now that everything is built into nice and neat modular plugins, where does that leave the actual theme. Again my thoughts on this are strong. The theme should only contain “view code” i.e. theme files and styling. Your functions.php is going to be quite bare as all the heavy lifting is done using plugins.

By adopting the above approach to building websites on WordPress, I’ve definitely found that they’ve been far more manageable and maintainable.

 

Creating simpler, better and LESS WordPress plugins

There is a well known software design paradigm that is called “Convention over configuration“. At its core, it aims to make software development easier by reducing the amount of decisions that a developer has to make when writing software.

It accomplishes this by providing the developer with a set of rules or conventions to follow. That in turn reduces the amount of configuration and scaffolding needed to get to the software built.

The most common example that gets thrown around is that of a class to database relation. If your class is called “Posts” your database table name would be called “posts” too. No mappings or configuration required.

By following defined rules and conventions, developers can almost always build their software in a standardised way. That means writing less code and focusing on what they’re really good at, solving complex problems.

Some of the biggest and best software frameworks and libraries are built upon this design paradigm, and for good reason.

What if however, we approached the paradigm from a different angle. What if we applied it to how we design our WordPress plugins from a users perspective rather than software design perspective?

Creating simpler, better and LESS WordPress plugins

What does this mean and how do we achieve that? Simply put it means designing your WordPress plugins using an acronym I’ve come up with called LESS. LESS is a recursive mnemonic acronym (something similar to KSES in the WordPress wp_kses function) and it stands for…

  • LESS – Apply the principles of LESS
  • Eliminate – By eliminating, we aim to get rid of any configuration, functionality or features that are not absolutely essential to the function of the plugin. It means giving the user only one way to do something. It means creating plugins that do less but offer more.
  • Standardise – To standardise means to do the same thing, in the same way, over and over again. A good example would be having multiple different plugins which are written and behave in the same way. Same naming conventions (preferably inline with WordPress standards), same type casing, same UI (see next point), same same same.
  • Seamless – Lastly your plugins should seamlessly integrate with WordPress. Your plugins should feel as if they’re a Core feature. Only by a user deactivating the plugin should they realise that it is not core functionality. Not only that, they should implement filters and actions religiously.

The benefits of writing LESS WordPress plugins

Applying the LESS principles to your plugins is definitely not always easy. It takes discipline and a real understanding of what your WordPress plugin is and what it is not.

It means turning down feature requests (and even pull requests for open source plugins) because they don’t always fit with the vision for what your plugin is.

However, by applying that discipline and knowing your plugin or plugins deeply, there are multiple different wins that you will notice…

  • Much easier and reduced support load. As long as you make sure your documentation and FAQ is as good as your software (an important topic for another day), you will receive far fewer support queries. Why? Well because there is simply just one way to do something.
  • Your plugins are more extensible. In fact extensibility is a feature and if someone want’s to go beyond what you provide with your plugin, they’re easily able to do that. It’s a selling point.
  • LESS is more. By simplifying and almost dictating how a problem is solved through your plugin, you are helping people by reducing the amount of decisions they have to make. That’s hugely beneficial and frees up their time to focus on what is more important to them.

Applying the LESS principles to my own WordPress plugins

I’ll admit, I haven’t always applied the principles to the many plugins that I’ve written. That’s mostly because from my part, coming up with the LESS principles took a lot of experimentation, creating and learning the hard lessons of NOT following the principles.

Right now, my next step is to completely rewrite WP Most Popular and apply the principles to that plugin. Even though it’s well on it’s way to becoming a LESS WordPress plugin there is still more work to do on my part.

How can you apply these principles to your own plugins? I would love to hear your thoughts.

PHPStorm for WordPress development

Why are many of the top WordPress developers using PHPStorm for WordPress development?

In December 2015, I landed my dream gig as a full time WordPress engineer at XWP. I had not been a full time WordPress developer, let alone PHP developer for 3 years running. I was just coming out of the payments world and the only exposure to WordPress and PHP that I had during those 3 years was the occasional client project that I did on the side.

Prior to that 3 year stint, I was doing WordPress development full time. Let me tell you, a LOT changes in 3 years, especially in the development world. So having been out of the WordPress development space for that amount of time, I had lost touch with a lot of the advancements around WordPress development tools.

With half a month left on my employment contract, my new full time WordPress role was fast approaching. I needed to get my development environment setup for maximum productivity so that when I start the new gig, I would be ready for the work that was going to be thrown my way.

The most obvious place to start was finding a good text editor (or so I thought at the time). So I started searching for text editors with excellent WordPress support.

I was quite surprised to find that during my search, an IDE by the name of PHPStorm kept getting a mention. Stack overflow posts, forum threads, mailing lists, tweets and Quora.

I’ve never been a big fan of an IDE. I’ve always felt that they’re bloated, slow and over kill for what I need. Sound familiar?

In any case, I was coming back in to WordPress development with an open mind and knew that I needed to give PHPStorm a try due to it’s popularity. And so, semi-reluctantly, I did.

It really didn’t take long for me to become hooked. I dumped Sublime Text and very quickly transitioned to using PHPStorm for all my projects.

Now, switching to an IDE from a text editor is definitely not for everyone. There are fundamental differences between the two that you will either love or hate. I would however encourage you to give PHPStorm a trial run. Watch some of the videos below to see what it is capable of and with an open mind, explore whether it could work for your situation. You might surprise yourself just like I did.

So, why use PHPStorm for WordPress development?

To come back to the question that was originally posed at the start of this article, there are a number of reasons. Let’s take a quick look at some of them…

  • PHPStorm has the best WordPress integration I’ve ever seen. No jokes, I have yet to find an IDE or plugin for a text editor that understands WordPress as deeply as PHPStorm does. Not only does it have autocomplete and documentation for all WordPress functions, it will allow you to autocomplete actions and filters too. You can cmd-click your way to the inner workings of WordPress and really deeply explore how things work in WordPress. What about WordPress syntax formatting? Yep, it’s got that too. You really need to experience it to see the true value of the integration.
  • Of course, it offers so much more than just excellent WordPress integration. Because it’s an IDE, there is no real need to ever move outside of it for 3rd party application support in the form of database access, Git tooling, FTP etc. Everything you need for developing a theme or plugin is in one single place. A great video to give you an overview of all the features is the one below entitled “Introduction to PHPStorm”.
  • Probably the thing that surprised me the most was that PHPStorm is not as slow and bloaty as I had expected. In fact, it was quite zippy. If you really are feeling withdrawal symptoms from your text editor, you can pretty much make the IDE look just like a text editor. The interface is clean and it runs smoothly on my 8GB Macbook Pro.
  • Since PHPStorm is built upon Jetbrains architecture, you have a full access to a whole bunch of extensions and plugins for the IDE. There are a ton of useful plugins and remember that the IDE comes with built in support for more than just PHP and WordPress. It handles Javascript, CSS, HTML etc extremely well.
  • It’s also really nice that PHPStorm is cross platform. If you run on more than just one operating system, it’s perfect to have installed across systems for development continuity.
  • PHPStorm ships with all the shortcuts that you would expect to see in a text editor kitted out with a whole bunch of plugins. You’ve got shortcuts to find files, classes, methods, IDE functionality and so much more. The navigational shortcuts are also excellent.
  • Lastly, probably the number 1 killer feature for me, is the debugging. Are you still using var_dump and print_r with a whole load of manual browser refreshing? You need to check out the debugging features in PHPStorm. This is so huge that in the coming weeks, I’m going to write a complete guide to debugging with PHPStorm.

The only real downside of PHPStorm is the cost involved. You pay a monthly subscription for the software, but it is so minimal that the value that you get from the software far outweighs it’s cost.

PHPStorm video tutorials to get you started

So to close off this article, I’ve recorded a whole bunch of videos which you can use to get up to speed on PHPStorm for WordPress development. There is no particular order that you need to follow in watching these videos and they’re quite short and to the point.

Introduction to PHPStorm
Introduction to PHPStorm
10 "must know" PHPStorm shortcuts
10 "must know" PHPStorm shortcuts
Database Support in PHPStorm
Database Support in PHPStorm
Using Git in PHPStorm
Using Git in PHPStorm
Connecting to and syncing with remote hosts in PHPStorm
Connecting to and syncing with remote hosts in PHPStorm
Setting up Vagrant in PHPStorm
Setting up Vagrant in PHPStorm
All about the Terminal built in to PHPStorm
All about the Terminal built in to PHPStorm

I hope by now you can see why many developers are turning to PHPStorm for WordPress development. Give it a try and let me know how it goes, I’d love to hear how it works or doesn’t for your workflow.

Who is the WordPress REST API really serving?

There is a saying that goes like this, “Beauty is in the eye of the beholder”. It’s true. How many times have you bought something that you loved and shown it to a partner/friend/colleague etc and not gotten the response or reaction that you had expected?

If you’re anything like me, it happens often.

Well the same is true in software. Don’t worry, we’re not going to go in to the ins and outs of beautiful user interfaces. What I am actually talking about here is slightly different and that is…

Software is really only beneficial to someone who has a problem that the software can solve.

Would you agree?

So by releasing software, your goal as a creator is to get it in to the hands of people who have a problem or challenge that your software obliterates.

What problem is the WordPress REST API attempting to solve and for who?

Let’s examine the WordPress REST API. There has been a lot of chatter recently on blogs and Twitter about the pros and cons of building out a full API spec supporting all of the WordPress features verse iteratively releasing the API as it is being developed.

Until recently, I was firmly in the camp of iteratively releasing the API, but the more I think about it, the more unconvinced I become. Let me explain.

Like a proverbial half built house, while it’s possible that someone could move in and live there, it’d be rather uncomfortable. The WP REST API has come a very long way and is an extremely important piece of WordPress functionality. In fact it’s as big as the addition of custom post types in version 3.

Because it’s that big, it needs to be done right. Doing it right obviously has little to do with doing iterative releases or one big single release. However, doing it right does mean more than just releasing an API that works in certain contexts.

Doing it right means releasing something in a package that would satisfy the needs of the intended audience. Like we mentioned above, solving a real life problem.

Many people in the WordPress space (and potentially you too) feel that the intended audience of the WordPress REST API is developers. And if that were the case then I would agree, release the API in it’s current form and iterate. But as I will try convince you below, while developers are an important piece of this puzzle, there is much more to the WordPress REST API than an API for developers to play with.

So, who is the WordPress REST API really serving?

The big winner at the end of the day is not initially going to be the end user i.e. bloggers.

Yes, they’ll benefit eventually once the experience improves because we’re building a platform on top of bleeding edge technologies. But that will happen over time. Can you think of a single piece of WordPress functionality that our users are missing out on because we don’t have a REST API?

There is a reason why there is only 20 something plugins using the REST API in the repository currently. That’s not the audience who will benefit the most.

In my mind, the WordPress REST API is going to initially serve 2 clear stakeholders…

The first is the much smaller stakeholder. Developers. Why? Because as developers we can stay relevant in the web development space by adopting new modern development frameworks. Because we can now use WordPress for more applications than just a blog or CMS. Because we can now offer much better mobile application experiences to our audiences. Because now more businesses will consider WordPress as a platform as it can integrate with existing systems easily.

And right there is the second stakeholder and the largest by far; business!

The WordPress REST API is going to mostly serve the needs of business. Businesses will now start taking WordPress as a platform a lot more seriously. Where before there was a narrow path for business to integrate in to WordPress, we’ve now got a 5 lane highway.

Why the WordPress REST API is going to be used mostly by businesses

The key area where I see the REST API being used almost exclusively is not really for next generation publishing platforms, but for integration with existing platforms.

Good businesses care about connecting with their customers to keep them happy and coming back for more. They also care about reaching potential new customers to grow margins. What better way to do this than by integrating with 25% of the web? Savvy businesses have already seen this opportunity and are moving swiftly.

WordPress will become way more than just a blogging or internal intranet platform to businesses now. It suddenly can be integrated in to existing CRM systems for instance, with little hassle. They can now import their existing content in to WordPress much more easily. What about their mobile experiences? Yep, WordPress can be the backend to those.

Existing social and publishing businesses can now easily start pushing their platforms on top of WordPress. Think of a completely unrelated example of Twitter data showing in a Slack feed. Well now you can easily have those kind of integrations pushing data in to WordPress.

WordPress also becomes a viable option for quickly putting out a MVP or proof of concept application with a fully fledged REST API. Got a development community, let them play around with it!

We’re going to see companies build products on top of WordPress like never before. There’s so much more opportunity opened up to business by simply providing them with an easy gateway in to the WordPress platform via a REST API.

The challenge the WordPress REST API team faces

So here is the challenge that we currently face. I’m putting it to you that business is who the WordPress API is being built for but business wants a polished product. They don’t want something half finished with the promise of more. Business really tends to look at things in black and white. To bring back our running metaphor, business doesn’t want an office without a roof.

And because I believe that at the end of the day, business is really who the WordPress REST API should be serving, I believe that the right path here is to give them something that is polished. Something they can pick up and start using immediately. We don’t have that just yet.

We will soon enough, the team working on it is doing an excellent job of making solid progress each week. Once the API supports every feature of current WordPress, then for me personally, I will then feel that it is ready for business.

Of course for the more forward thinking businesses, they can use the plugin in the interim, knowing that when it is merged in to core, they’ll be ahead of the game somewhat.

If at the end of the day, we serve the intended audience of the WordPress REST API and we agreed that business should be that benefactor then we’re on the right path.

If not, we’re making a mistake and we’ll learn from it. Either way, we’re walking a path in to somewhat unchartered territory and we’re going to make mistakes and bump our heads. That’s how we learn. That’s how we move forward.

So where to from here?

Clearly, there are a lot of different opinions being thrown out and we need to be aware of those and rather than tear them down let’s be really be supportive of each other. Don’t dismiss something that you don’t agree with, try to look at it from another perspective.

Most importably, we all need to be respectful to the team doing the hard work on the ground. Not everyone is going to agree on the best way forward but let’s continue to discuss the issues at hand and “iteratively” 😉 work on it.