If you’re running a business that focuses both on developing solutions from the ground-up or that focuses on implementing a custom solution in the context of pre-existing projects (or maybe both), then you’ve likely – at some point – been in the situation of inheriting WordPress projects.

Tackling projects from either handle brings its set of challenges – most of them welcome  – but it seems to be far more common place for people to complain about working with a pre-existing codebase.

It’s not that I don’t get that feeling, but I do think there’s a level of immaturity in doing that. On the one hand, yes some codebases are outright terrible. But then some codebases aren’t that bad. In fact, I’d argue they are just a little bit different from how you’d develop it.

This is a case in which standards come into play, but I digress on this for now.

So let’s say you’re inheriting WordPress projects and you’re not particularly stoked about the codebase with which you’re working. How is it that you can still enjoy the work that you’re doing without feeling like you need to critique every aspect of whatever it is with which you’re dealing?

Continue reading

Last week – and this weekend – I’ve been reading the comments on Pippin Williamson’s posts about his company’s decision to adjust prices on Easy Digital Downloads (and for those who are curious, I applaud it).

That’s a conversation in and of itself, and there’s a long comment thread that I think is worth reading for anyone involved in WordPess product development, but I digress as that’s the point of this post.

Some readers have left comments throughout the comment feed discussing the notion of community-based support forums. The whole thread is worth a read but:

1. EDD used to offer community-based support forums (in addition to their other support),
2. I’ve built and worked on products that had community-based support forums

And, in retrospect, I absolutely do not think it’s a wise decision for a WordPress-based product shop to offer them. I have my reasons, I’ll elaborate, but I want to be clear that I’m constraining this strict to WordPress because it’s what I know.

I can’t speak for any other segments of our industry.

Continue reading

Last week, I gave my presentation at WordCamp Atlanta on Namespaces and Autoloading. (the full title was Namespaces, Autoloading, and Improving Plugin Architecture but that’s a mouthful, isn’t it?)

Because of the nature of the talk, I’ve opted to write a post to accompany the post, share the slides, and share an example plugin GitHub to help support the talk.

So if you were in attendance, thank you(!) and here’s the post, I promised. And for those of you who didn’t attend, I hope this post still helps to demonstrate the concepts and topics I discussed at WordCamp.

Continue reading

Though I have a suite of tools I prefer to use on projects that I work on from the ground-up, the nature of contract work is that you’re not always able to use those tools.

Instead, you have to work using the tools provided by the client which usually come into play whenever you inherit a project from a previous developer.

To be clear, this isn’t knocking anyone’s choice of tools. I don’t have a position here or there on that. Instead, I think it’s import to know how to get up and running with some of those tools easily.

For example, we’ve been working on a project that requires Gulp which in turn requires Node which can be installed easily using Homebrew. It’s a lot of steps to work backward, right?

To get started with Homebrew, Node, and Gulp in WordPress development is pretty easy. I’ve outlined the steps below and done what I can to explain what each package does so you know what you’re installing and what you’re doing if or when you encounter a project like this.
Continue reading