Page 251 of 429

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.

Upload Files to the WordPress Media Library

September 23, 2014 / Tom / 0 Comments

Programmatically uploading files to WordPress is really just the same as uploading files from any source location to a destination.

That is to say, there are a number of PHP functions all of which make it pretty easy to deal with file-level operations, grabbing files from one location, and moving them to the next.

And yes, there are some nuances that can come with PHP’s configuration such that you may not be able to write to certain directories, perform certain options via HTTP, and so on. All of these can be managed by either changing up the configuration or by changing the way in which files are handled by the code.

The WordPress Media Library

One thing that WordPress offers that manual uploads don’t manage is adding files – specifically media types – to the Media Library after uploading a file. This is relatively easy to do given media_sideload_image.

But let’s say the situation is a little more complex.

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.

Tom McFarlin

Open Source Challenges: Software Identity

Upload Files to the WordPress Media Library

Testing in WordPress: Scenarios and Spreadsheets

Writing Maintainable WordPress Code: Plugins

Pragmatism in WordPress: On Agility