Adopting Pro Workflows Now that WordPress Is All Grown Up

I remember setting up my first WordPress blog. I spent hours following guides online to download WordPress, trying to upload it again and then figuring out how to set up a database.

I just FTP’ed every change right up to the live server, and hoped the blog didn’t go dark if I mistyped a question mark.

WordPress has grown up in the meantime. Massive media companies use WordPress as their principal way of communicating with the world. Go to Tech Crunch or the New Yorker and view the source html. You’ll find that the website is built using WordPress. Beyonce? Yup. She digs WordPress.

At the same time WordPress has this terrible reputation amongst developers. The stereotype is of script kiddies uploading files via FTP, no using version control and generally abandoning every sane principle of software development known to mankind.

Obviously, it’s not a fair accusation. WordPress has grown up. It’s getting a fully-fledged REST API this year. You can now install WordPress and dependencies from the command line using WP-CLI.

WordPress developers and theme designers are growing up. Roots.io is an example of treating WordPress projects like any serious software development project. They don’t mess around with drag-n-drop FTP uploading. Instead, they use git for version control and capistrano for deployments.

Joel of Fog Creek Software famously wrote about 12 steps to better software, and one of those was an issue or bug tracker. He is right. It’s hard to remember all the various different feature requests and bugs in your head. It’s even harder to remember all the steps to reproducing bugs, what the user expected and what they actually got.

There’s only so many post-it notes you can on your desk, as well. WordPress itself uses Trac as its issue tracker. I’ve worked with Redmine, another open-source issue tracker and project management tool, because I’m at Planio, which offers hosted Redmine and git hosting.

The Typical Use Case of an Issue Tracker

So, imagine you’re building a new plugin for WordPress. You’ve got a small team on the job – a developer or two, a designer and a business guy.

You’re no longer a team of just one person. You don’t all work in one location, because, well, remote work is awesome, and the northern hemisphere is not so much fun in the winter.

A user sends in an email saying that the plugin “doesn’t work”. If you’re truly lucky, you’ll get a screenshot showing an error message of “doesn’t work”.

You forward the email around. Someone emails back with a question of what browser they were using, and all of a sudden you have a Gmail thread of 12 emails. There’s a few problems wrapped up here, and issue trackers help you solve these problems.

The Three Critical Pieces of Every Fixable Bug

The first is that you actually need three things for every bug report:

1. What steps did the user take that resulted in the bug?
2. What did the user expect to see?
3. What did the user actually see?

You need to be able to reproduce the bug, because it’s really hard to fix a bug you can’t see in action. Second, you have to make sure the bug is, in fact, a bug or whether the user expected something your software doesn’t provide.

Here’s another way of putting it:

A parent's rules for bug reporting:
– What did you want the program to give you?
– What did you do to the program?
– How was it mean to you?

— Steve Purcell (@sanityinc) October 29, 2015

And you can’t fob off the person reporting the bug with the classic line: “It’s not a bug. It’s a feature!” if you don’t know what the person expected instead.

Using an issue tracker such as Redmine means you have a standardized way of receiving this information.

There’s one way you can make sure a task never gets done: vaguely suggested that the team should do something about it. Unless it’s assigned to one “owner”, it just won’t get done.

Issue trackers force you to assign an issue to, well, one person at any given time, so you always know who currently owns a bug or task. At the same time, issues go through a workflow of different statuses such as “In Progress”, “QA/Testing” or “Ready for Deployment”.

Most trackers will give you reports based on the current status of an issue, so you can see the current volume of work in progress and how much remains to be done. You can even create burndown charts, which are popularized in agile methodologies.

Tightly Integrate Git into Your Project Management Workflow

As we mentioned above, using git in your WordPress development process will make your life a whole lot easier when things go wrong. Git gives you a rewind button on your code, and you can create multiple, parallel versions of your site.

Every time you “commit” new code to your git repository, you’re creating a natural point to discuss the change to the codebase. In addition, I find it’s easier to discuss problems based on actual committed code rather than just vague ideas.

That’s where issue trackers shine, because Redmine, for example, is tightly integrated with git or svn. You can quickly see who committed what against issues and then discuss those issues.

Create a System for Your WordPress Development

An issue tracker will help you scale beyond just yourself. You’ll be sure that issues aren’t slipping through the cracks.

At Planio, the majority of our customers use our hosted Redmine for the purpose of tracking software development projects, including WordPress projects. They track bugs, new features, and sprints in connection with version control.

Redmine, like WordPress, is open source, so you get the advantage of not being locked into proprietary software. And like WordPress, you can outsource hosting to someone like us at Planio, or you can install it yourself if you prefer from Redmine.org.

Over To You

So – how to you manage your workflows? Have you tried Redmine? We’d love to hear your thoughts and comments below!