Category Archives: WordPress

I get a fair amount of project inquiries. One of the biggest things I see is people wanting small WordPress plugin customizations. I don’t mean small in the sense of change a line or two of code, I mean small in the sense of changing how part of the plugin works. Changes that may take a half day or up to maybe two days.

I even get requests that involve wholesale changes to how a plugin works, these types of changes can take up to a week’s worth of development time. Though this isn’t really “small” in my book, it usually still is in the eyes of the requestor. They don’t understand the mechanics of why a “premium” plugin costs $49 (or $99 for that matter) and add-ons cost $19.

To make that assumption is to throw out basic principals of how things are made. The plugin may cost $49, but that wasn’t the cost to make the plugin. Hundreds, perhaps thousands of hours went into the initial plugin creation. The plugin developer makes this back on sales of the plugin. If 1000 copies are sold, they’ve grossed $49,000.

The same goes for add-ons. Depending on complexity, they can be made in a day, or over the course of a week or so. Selling 100 copies of one for $19 gets the developer $1900 towards the cost of development. Common-use add-ons are great. You generally won’t see an add-on that only 5 people may use. Either it’s more expensive or the developer would never make back the cost of building it.

I’m not going to complicate things at this point on how products are bundled and priced to add value and drive sales, lets just stick with basic math for the sake of this argument.

The custom shirt scenario

Have you ever looked at the cost to screen print shirts? The more shirts you buy, the cheaper the cost-per-shirt becomes. Sure you can get 1 shirt made, but it’s going to be expensive. The screen still has to be made whether you use it 1 time or 100 times.

But if you get 100 shirts made, the cost to make the screen is divided out over the shirts produced. The same goes for plugins and add-ons. The cost can be divided if it’s re-sold as a generic add-on, but this doesn’t apply to the single-use customization someone requests.

Now, when you contact someone to do custom work on a plugin and change how it works, you need to understand that you’re paying for time.

For a beginner developer this may be $35/hour. You might expect to pay closer to $100/hr for a seasoned developer, and upwards of $150 to $200 (or more) for an expert. Choosing a developer is a topic for another day, but keep in mind– if your customization is going to take a day, expect to spend more than $500 to make it a reality. You’re paying someone to make something custom for you that they aren’t going to resell.

Assembly Lines and Customizations

Henry Ford revolutionized the Auto and Manufacturing industries with the invention of the assembly line. The best part of the assembly line is that it works great when you’re doing the same thing over and over. Ford was able to assemble a Model T in 97 minutes.

The downside to the assembly line is that it didn’t allow much room for customization. If you wanted a custom product, it was usually still made by hand; and at the time, hand-assembled automobiles cost more than assembly line automobiles.

The Bottom Line

In the end, if you want custom work, understand the mechanics of your request. You’re asking for something custom that isn’t going to apply to anyone else. If you need something super custom, be prepared to pay for someone who knows the ins and outs of the systems you plan to use.

As the requestor, you have to afford the full development cost. If you can’t do that, assemble a solution based upon what plugins and extensions exist. That’s the inexpensive way out.

You walk into a fancy bistro for dinner. The chef has crafted a wonderful three course meal for his guests this evening. He’s carefully picked ingredients that compliment each other and make three wonderful dishes. Along with those dishes, he’s paired a wonderful wine selection. You eat your meal. It was delicious.

When doing web projects for clients, your role should be similar to that of a chef. It is your responsibility to pick the ingredients (plugins, themes, code) to make the dish (project) come together. But it doesn’t end there, they need a fine wine (hosting) to compliment it.

Looking at things this way gives a good illustration of all the pieces involved to launching a successful web project. Hosting should be paired depending on the scale of project you’re doing. You wouldn’t pair a light white wine with beef entree; the beef would overpower the wine. Likewise, you wouldn’t pair a heavy red wine with a delicate fish entree.

More often than not, I see hosting mis-paired for web projects though. With more and more specialized/niche hosts appearing it’s key to remember everything isn’t one size fits all. A host with a great cache setup might be good for content driven sites where the site is for the most part read-only. That doesn’t really work when you have a lot of moving parts like dealing with sessions (e-commerce) or geolocation.

Knowing how to pair projects with hosting will save you the pain of developing an awesome project for a client then falling flat on your face when rolling it live. I’ve learned those lessons before– the hard way.

There are two variations of it– WordPress, and WordPress Busy. The only difference is that the latter hides events (join, part, nick, etc), which I find very useful for very busy rooms. Hence the name. 😉

To install download the zip file containing the styles and image, unzip and drag the variants folder into ~/Library/Application Support/Colloquy/Styles/

From there you should be able to activate the style in Colloquy from Style > Standard > WordPress / WordPress Busy

In sticking with the busy developer mantra of “I’m too busy to update my own site’s theme” I did what I usually do and update to the the latest WordPress default theme. Now featuring TwentyTwelve instead of TwentyEleven.

I set up my first WordPress site back in 2004 when WordPress was a very immature project. It was a great site and there were some good discussions, but due to some circumstances in 2006, it led me to delete my blog and all my content. It wasn’t necessarilly “deleted”, but taken offline.

About 2 years later, near fall of 2008 I set up my site again. Just to get something going I started from scratch and never imported the content. There were some bad memories with some of the old content. I wanted to move on.

Over the past 6 months or so I had toyed with re-importing the content. I had the backup. The last version I had run with the old site was 2.0.4. Today I decided to pull the trigger and import the old content.

I’ve imported 439 posts into this site. Now I have archives back to 2004. In September it will be 8 years I’ve been using WordPress– since version 1.2. It truly is an awesome publishing platform.

I ran across an issue today where I needed to specify which image sizes were generated within WordPress. I didn’t need the stock sizes (thumbnail, medium, large) but I did need a few custom sizes. Adding custom sizes is the easy part but removing others threw me for a loop.

The quick and dirty solution would be to set the sizes in Settings > Media to 0 so that nothing would be generated. While this works on a single site, its not the best solution for something that would be deployed on multiple sites. After all, who wants to remember to change individual settings on each new site?

Best solution, filtering intermediate_image_sizes. Basically all you need to do is return an array of what sizes you want generated. In the example below, I had already used add_image_size() to generate 3 new sizes: theme-small, theme-medium, and theme-large.

I’m sure you’ve heard about the debate with WordPress vs WordPress. There was a patch committed to WordPress 3.0 that automatically converts it to include an uppercase P and follow the WordPress branding. This was added as as an easter egg of sorts to help the WordPress brand, and while I don’t have an issue with it, I do have an issue with the way some in the community reacted to it.

The problem with easter eggs is they’re supposed to be found by those in the community and they’re supposed to be fun. Of course, there was no hiding this one. The revision was committed in the public eye, but without a ticket. I don’t think there was much need for a ticket and public discussion because this has been in play on WordPress.com for a few years now. Of course, some argue that there was no community input because there was no trac ticket.

The one legitimate issue I could find with this patch was the fact that because the way it corrects text, it can possibly break image links and directories. I’m sure this is only in a minor percentage of cases, because as most have learned, their hosting environment is case sensitive and they use all lowercase directory and file names. This has since been fixed for trunk and 3.0.1 in revisions 15377 and 15378.

This begs the question, if this patch worked properly and didn’t break links, would we even be in this situation? Would the few squeaky wheels be complaining about Matt and Automattic doing their will and not respecting the community? Would this issue have been blown out of proportion? Would anything have even been said about it?

As usual, some in the community to complained. I’ve heard all sorts of excuses from editing user’s content (albeit just a spelling correction), to the capital P caused the BP oil spill. Yes, I’m not joking. Conspiracy theories breed conspiracy theories. There have even been parody sites made– capitalp.org and lowercasep.org

This brings about another point– I recently had a discussion with Aaron Brazell regarding the WordPress community and complaining. The point he made was that if it doesn’t affect your bottom line (income) stop complaining about it. All you do is waste your breath, waste your time, and don’t make as much money as you could. By directing your resources to other places, such as your business or contributing patches to WordPress, you can further better yourself and the WordPress community.

As usual though, there’s always a few that want to complain, and while I won’t mention them by name (they know who they are), I hope they take one thing away from this post– focus your time on making WordPress and the WordPress community better instead of complaining about this or that. Please stop coming up with conspiracy theories about Matt, WordPress and Automattic; they’re rarely true. Its not an issue of principal, Matt, or Automattic; its an issue of making things better. Focus your time on creating a patch to fix the filter and fix the bug. That helps improve the community.