Category: Articles (Page 185 of 258)

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

Steps for Soft Launching WordPress Products

August 8, 2014 / Tom / 0 Comments

One of the things with which I’ve just started experimenting is soft launches of product updates. That is, I’m providing updates to users of certain plugins through automatic updates in order to garner feedback – if any – prior to announcing it and launching it to everyone else.

For those involved in the software world, this is nothing new, but for those who are just getting into building products for others or who are looking for ways to test the proverbial waters of their projects without a public announcement for every single release, then this isn’t a bad idea.

Wikipedia defines a soft launch:

A soft launch is the release of a website, hotel, or other product or service to a limited audience. Soft-launching is a method for gathering data on a product’s usage and acceptance in the marketplace, before making it generally available as a hard launch or grand opening.

I think the idea of soft launches, open source, and the general WordPress economy is a really broad topic about which there’s a lot to discuss, but I thought I’d share some quick ideas based on my experience for those who are looking for a process on how to perform soft launches of their work with their existing customer base.

Code Quality, Disrespect, and Developers (Or “Do Not Be a Jerk”)

August 7, 2014 / Tom / 0 Comments

Yesterday, I received an email from someone who was kind enough to contact me about a security vulnerability that existed in one of my plugins (past tense because it’s been fixed :). This wasn’t so much an issue of code quality but potential security problem that could’ve been exploited by taking advantage of how PHP handles file uploads.

Generally speaking, this is one of the luxuries of open source – you’ve got other people who can spot vulnerabilities in your code and who can give you a heads up as to how to fix it. Of course, the flip side of this isn’t so nice – someone discovers a vulnerability, exploits it, and then you’re left dealing with whatever the fall out may come from that.

Lame.

Watch out for this guy. He’s after your code.

Anyway, the understood protocol with security vulnerabilities usually works like this:

The person who discovers the vulnerability contacts the developer(s) of the software to notify them of what they’ve found.
The author of the software has a chance to respond and/or patch the software.
Before the person who discovers the vulnerability opts to publicly share the story, the developers have 24-hours to provide a fix (or, at the very least, a statement about the problem).

This may play out in slightly different ways, but you get the idea. Naturally, you’ve got those who don’t follow this protocol at all, but that’s not really the focus of this particular post. Haters are going to hate and all that jazz.

Instead, one of the things that seems be happening more and more frequently is people calling other people out about the quality of their code via Twitter.

Should these situations be treated that much differently?

The Usability of WordPress Featured Images

August 6, 2014 / Tom / 0 Comments

Featured images (also referred to as “post thumbnails”) are nice features to include in WordPress themes, but there are times where I question their implementation.

I know, I know: talking about stuff like this can come off as frivolous, but I think that if you deeply care about what you’re working on, then evaluating the decisions – every one of them – that go into your product matters.

And since featured images are a decision that need to be made when working in theme development matter, then it’s worth evaluating their implementation.

Educate Your Users in Open Source Software

August 4, 2014 / Tom / 0 Comments

One of the things that I’m working hard to have released by the end of the month is the latest version of the WordPress Plugin Boilerplate.

The latest version has been in development for quite a while now (a lot has happened offline so, you know, that’s how it goes).

The last time that I really spent any time talking about this project was in November 2013. A lot has changed since then. Initially, I was planning on a minor upgrade with some of the following features:

Releasing the version has part of the 2.x.x versioning
Including a class specifically for administrative functionality
Fixing issues with symbolic links and textdomains
Including more TODO’s for users to find what needs to be changed
…and so on.

But when I got started on the next version of the Boilerplate, a lot of things changed. The short of it is that it’s being completely re-written from the ground up and the code and documentation are being split into to separate things for the sake of user education.

I’ll spend more time talking about the Boilerplate in a future, but one of the things that I wanted to share that’s related to running a project like the Boilerplate has to do with open source, contributions, lack of a vision, and how this can negatively impact your project and your users.

Start Nitpicking Your Source Code (Or Someone Else Will)

August 2, 2014 / Tom / 0 Comments

Earlier this week, a fellow WordPress programmer whom I respect (and who is doing amazing things with his Aesop Story Engine) shared the following tweet:

cheers to the nitpickers.

because it matters what’s on the side you don’t see.

— Nick Haskins (@nphaskins) July 31, 2014

Truth be told, I wasn’t sure if he was being sarcastic or not. This isn’t his fault, of course, but my own ability to discerns, y’know, tweets. So I did what anyone would do in that situation: I asked him if he was being sarcastic or not to which he replied:

nope no sarcasm there. the nitpickers provide amazing value

And he’s right.

Someone is going to be nitpicking your source code.

This post is not about my opinions or observations as to how we tear one another down online under the guise of trying to help one another (that’s another post for another time), but it’s about the idea for which I completely agree (and that’s mentioned in the tweet above):

because it matters what’s on the side you don’t see.

Because I believe it does, and because I think that a number of people are sloppy. There’s a just get it working mindset, and I’d love to see more people take pride in their work and stop shipping code that has the same amount of details “on the side you don’t see” as on the side that you do see.