Category: Articles (Page 180 of 258)

Personal opinions and how-to’s that I’ve written both here and as contributions to other blogs.

Debugging WordPress Projects with Log Files

September 26, 2014 / Tom / 0 Comments

There are a number of different ways that you can setup a debugging WordPress projects. It may be in the form of an IDE, it may be in the form of another application like MacGDBp, or it may be in the form of using something that fits your workflow.

Whatever the case, when a project reaches production, you normally don’t have access to any of the above. Instead, you’ve access to error logs. Obviously, they’re really useful when needing to, say, follow a stack trace for any given warning or error.

Sure, it sucks not being able to attach a debugger to your code on the server-side and then trace where the problem is, but given log files and pouring over enough information, you should be able to (well, at least hopefully) reproduce the error in both development and staging.

As such, I think it’s valuable not only to have quick access to error logs for WordPress in your staging environment but in your development environment, as well.

Open Source Challenges: Software Identity

September 24, 2014 / Tom / 0 Comments

A couple of weeks ago, I made the move to Overcast as my primary podcast application on my phone. I absolutely dig it, but one of the things that I respect most comes in the FAQ of the application:

There’s a very basic web app. An iPad app is planned. A Mac app might happen someday.

I have no plans for other platforms at this time. It’s nothing personal: they’re just not for me.

Overcast was clearly built for a specific purpose – on that was largely personal – and there’s no intent to grow it beyond that specific purpose.

I love that.

Overcast

And when it comes to our own work, there’s something to be said for building tools that help you do whatever it is that you want to do, and if you’re looking to market it great, and if you’re looking to keep it only on your machine or as a tool for your own project, then that’s great, too.

But in a segment of the industry that praises open source and the advantages that come with it, it can be somewhat of a challenge to have tools that you build only for yourself and have them maintained for that single purpose.

Testing in WordPress: Scenarios and Spreadsheets

September 22, 2014 / Tom / 0 Comments

Testing software is one of those topics that people often talk about, write about (books even), and evangelize during conferences, meet ups, and so on. And rightly so – testing is one of the most important aspects of building something that’s going to be used by others.

Sometimes though, I wonder if we don’t do more talking about testing than actual testing.

By that, I mean we all understand its importance and I’d venture to say that we’re relatively familiar with the tools that are available for testing, but the act of testing in and of itself is kind of a beast:

It requires that you install additional software on to your computer
It requires that you learn how to write tests using the above software
It introduces more code thus more time into a project which doesn’t always translate well for stake holders
…and more

In short, there’s a lot working against it. I get it. Even more so, we talk about all kinds of testing – anything from unit tests to beta tests to release candidates and so on. All of these are important and they all have their place, and testing in WordPress is no different.

That said, there’s at least one method of testing that I think is applicable but rarely employed when it comes to creating themes or plugins. It’s an intermediate step of testing that I would say fits between user testing and beta testing: Use case testing (perhaps there’s a better title for it, but that’s what I have for this post).

Writing Maintainable WordPress Code: Plugins

September 20, 2014 / Tom

The comments on this post are closed. Please leave your feedback on each of the respective articles.

Regardless of the type of software that you build either for a living, for a hobby, or for both, one of the most challenging aspects of the field is trying to write maintainable code.

That is, code that’s organized, follows a standard, is easily read, and adapts to change over time as the environment and requirements of the overall software changes.

It’s not an easy task and people far, far more experienced than I am are still talking about how to do it.

Still, that doesn’t mean that those of us who have been working in WordPress for some time haven’t learned some strategies for works, what doesn’t, and what’s proved to be maintainable WordPress code throughout the years of development.

Pragmatism in WordPress: On Agility

September 19, 2014 / Tom / 0 Comments

Dave Thomas, for those who aren’t familiar, is a notable programmer for both co-authoring The Pragmatic Programmer and for running the The Pragmatic Bookshelf company. In my opinion, he’s a fantastic person to follow if you’re into programming of any kind.

A few months ago, I stumbled across an article that he had written (that many of you have read) entitled Agile is Dead (Long Live Agility). It’s a great read for anyone who’s interested, and though I’m not particularly interested in talking about all of the things his article hits on, there are two specific things that I found relevant to anyone who is just getting started writing WordPress code, or who has been writing WordPress code for sometime and may need a refresher.