My Workflows For WordPress: Hosted Projects

If you’re like me, then there’s a part of you that’s obsessed highly motivated to make sure that you’re streamlining your workflow as much as possible.

When it comes to the process of working on WordPress plugins, WordPress themes, and how to manage everything via source control, support forums, and managing bugs and their associated tickets, all the while making sure that you’re not duplicating repositories in order to make sure you’ve got the leanest workflow possible can be a bit of a chore.

Even writing (and possibly reading that last sentence) is just as indicative as to how tedious it can be.

So, with that said, I thought I’d share my workflow for how I divide up my codebases based on if they are hosted in the WordPress plugin repository and/or the WordPress theme repository, and how I deal with support, as well as how I manage self-hosted projects and their associated support forums, as well.

In this first post, we’ll cover the former.

Workflows For WordPress: Hosted Projects

The reason I’m dividing this post up into two parts is because if you’re working with WordPress, then there are likely two different versions of source control systems you’ve worked with, a few different options as it relates to managing support, and a wide array options to choose from for tracking bugs.

Personally, I see everything related being a result of where your primarily storing your codebase – everything is tangential to that.

I know that some people are doing clever things by syncing up their Subversion repositories and their GitHub repositories, and I’m all for that if it works for them. But, for me, it creates more work than it’s worth.

With that said, here’s how I end up dividing up my various solutions based on what type project on which I’m working.

Specifically, if I’m working with a project that’s a WordPress plugin hosted in the repository, or a theme hosted on WordPress.com, then these are the tools that I use.

Source Control

Since WordPress plugins and WordPress themes are all based around a Subversion repository, then I make sure that it’s more-or-less the filter through which I make decisions on how I handle support, and issues, as well.

But in terms of keeping track of my actual software, I use Cornerstone.

There are a number of other applications that are available for handling subversion-baed projects (such as Versions, which I also recommend – especially if you’re looking for Subversion made simple).

I don’t do any cross-references through GitHub, nor do I have a GitHub repository for managing the code that also exists in the plugin repository or the themes repository.

The only caveat to this is if I am currently developing a plugin that’s not yet ready for release. In that case, then there’s a strong chance I’ll use a GitHub repository until it’s ready for release. Once it reaches that point, I kill the repository.

I know, I know: I lose all of the source code history. I try to keep a detailed changelog so that, at the very least, I know when I made what changes.

Support Forums

When it comes to Support Forums for solutions that are hosted for plugins and/or themes, then I tend to use the solution that is made available out-of-the-box.

That’s a fancy way of saying that I just use the default support systems.

This saves me from having to spin up a new project, channel, or whatever you want to call it for a new project. On top of that, it’s more or less where the average user usually excepts to place their reviews, questions, and comments about the project.

The last thing I want to do is to redirect them somewhere else to share that information especially in the case that they already have a problem with the project.

How frustrating would that be?

And yeah, I know that sometimes those support forums may lack some of the nicer features that we have come to expect from larger systems, but they’re a simple solution and get the job done. They’re a common place for users to ask their questions, and that’s the most important thing to me.

I don’t want support to be hurdle for my users.

Issue Tracking

As of the past year or so, finding an issue tracker that I really like that isn’t also tied to a source control system, that supports multiple projects, tickets, labels, markdown, and so one, and that has a price that works well with projects that are usually released for free or for relatively little expense has been a challenge.

But for the past few months, I’ve been using Lighthouse.

If you’re used to GitHub’s system of tracking issues – which is honestly my favorite system that’s out there – then you’ll feel right at home with Lighthouse. I know this sounds a bit like a sponsored post, but it’s not – it’s just that I’ve been that happy with the solution especially as it relates to tracking bugs both for the beta version and final version of Mayer.

Right now, I’m using the free plan because it works well with the projects that I have, but as the project generate any kind of revenue, I’ll be able to scale my Lighthouse plan with the issues, as well.

There’s [Always] More

Obviously, this is only half of it.

My workflow is a little bit different for those projects that I host on GitHub. Sure, it contains all of the above – source control, support, and issue tracking – but the decisions for the software that I use in that case are, like those above, all based around the source control system I use.

In the meantime, I’m curious as to how you guys setup your workflow especially for projects hosted in any of the WordPress-specific repositories.