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.

Cornerstone For Source Control

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.

WordPress Support Forum

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.

Lighthouse Issue Tracking

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.

4 Replies to “My Workflows For WordPress: Hosted Projects”

  1. Tom,
    I recently added all the plugins that I have been authoring to Github. I use Github to maintain the most up to date version of the unreleased code. I like this because I’m able to implement a new feature and push it with its own changelog and continue doing so till the final version is ready for the plugin repository. At this point, I push the final version into the WordPress.org repository since that’s really where all the users are working on their plugins.
    For support, I stick to the WordPress.org forums for now.
    I’ve still got to get into the whole creating/tracking issues. I’ve just been maintaining a list of things to do in Evernote.

    1. I’ve used a similar workflow with a few previous projects, and I even went the reverse direction and put a couple of projects from the WordPress.org repository to a GitHub repository.

      This made it much easier for others to commit, to track issues, and to keep a nicer set of changes, but it also came at the expense of having to deal with the overhead of syncing back and forth between GitHub and Subversion.

      This isn’t a big deal for a lot of people, but it’s never been something I’ve particularly enjoyed.

      1. I’m currently using svn2git to mirror the WordPress repository and I keep rerunning it every time I push a final version to the respository. For some reason svn2git rebase doesn’t work for me.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.