We’re looking for someone with a broad range of WordPress and web development (PHP, XHTML, CSS, JavaScript) experience, comfortable working in a standard web hosting environment, and in particular someone with outstanding communication skills.

We welcome local Denver-area candidates to join us in our office or remote developers that have a quiet home office environment.

Providing great service is our number one priority, and we need someone to whom this is inherent. We have a responsibility to every affiliate plugin and theme developer who puts their trust in us and to the WordPress community as a whole.

See the job posting on the HelpCenter web site for more details and to apply. This position is open immediately and we hope to fill it within the next 30 days.

If I could only share one tip, it would be this: Take responsibility for your WordCamp experience.

Everything else I’m listing below can be summed up in that one piece of advice (and is true for just about any conference or meetup). It manifests itself in a variety of ways.

• If you aren’t enjoying/learning where you are, move. We try to cater to all attendees throughout the day, but not all sessions will interest everyone. There are normally multiple sessions going on at once, people hanging out in the halls, people at the Genius Bar or developer garages – if the session you’re in isn’t to your liking, take action and see what else is going on.
• Ask questions in sessions. Speakers love the opportunity to share things they know will be of value to their audience. They know they are doing this when they are addressing questions.
• Don’t be shy about approaching and talking to speakers. Most speakers I know really enjoy feedback, related discussions, etc. Plus, it gives them a nice ego boost.
• Aggressively seek out people you want to connect with. At a conference I often get more out of conversations at random times and places than I do out of the structured sessions. If there is someone you want to talk to, go find them – don’t regret not doing so afterward. The corollary to this is to be respectful if they are busy or for some reason aren’t interested in conversing with you.
• Find your own time for networking. Don’t rely on structured time to connect with people. Join a conversation between sessions, talk with people next to you. Chat up someone that asked a good question in a session.
• Lastly, Remember that this is a community event organized by community volunteers with the help of local sponsors. We try hard to get input from the attendees and structure the event accordingly. I can’t speak for other WordCamps, but I know that last year’s WordCamp Denver and this year’s WordCamp Boulder are just about break-even propositions for us. Please temper your praise and constructive feedback accordingly.

It’s been great to see how WordCamps have grown over the years and I’m very pleased to be able to help organize the Denver/Boulder editions. Keep up the community spirit and have a great time.

There are also micro-sponsor tickets available for those wanting to do a little extra for the community and participate in the speaker/sponsor dinner on 9th.

If you’ve already got your ticket, make sure to grab a badge as well.

We are setting up a Genius Bar at WordCamp this year, and I’m very pleased that members of our WordPress HelpCenter team will be there to help out. If you’ve got WordPress questions big or small, make sure to visit the Genius Bar.

A big thanks to our sponsors for the event as well – see the full list in the sidebar on the official site. As with ever WordCamp, the contributions of the sponsors are literally making the event happen.

You’ll get to work on a bunch of interesting and diverse projects. Some of our recent projects have included:

• Advanced WordPress websites, plugins, themes, integrations and products. We build a lot of stuff with WordPress.
• A site migration tool for importing legacy websites into WordPress multi-site (complete with testing routines).
• Facebook integration and platform development.
• A web service for processing gobs of data running on Amazon’s cloud. The system is comprised of 10 different individual components, all talking to each other’s web services.
• Customizable financial dashboards (web application).
• An integration into numerous web services to power a custom web application that provides a different kind of productized web analytics.

We have a casual, collaborative team environment. You can choose your OS and development tools (all of our systems are cross-platform or web based) and get to have a say in development approaches, policies, best practices, etc.

If these kinds of things sound interesting to you, we’d like to hear from you.

We also have two internship positions (developer and designer/front-end developer) available – if you want to learn about building with WordPress, Open Source, web standards and modern best practices, we can give you some great experience building things people actually use.

If you do need any help upgrading to WordPress 3.0, don’t hesitate to contact my WordPress HelpCenter team. You can call them directly at: (303) 395-1346 from 9am-8pm US/Eastern M-F or email anytime to help@wphelpcenter.com.

If you’re interested in learning about WordPress design or development, or want to get a good foundation in design/development for Open Source and web standards, this is a great opportunity. For the right individual, this position could lead to full-time employment.

You can stream or download the podcast here.

I wanted to publish a quick Q & A to answer a few things I’ve seen circling around:

What is included in the ticket price?

Your ticket gives you access to all event sessions, the Genius Bar (staffed in part by WordPress HelpCenter) the after-party as well as lunch and a snazzy t-shirt.

Will the event sell out?

It’s hard to say for sure, but last year’s WordCamp (the first in the Denver/Boulder area) sold out and we sadly had to turn folks away at the doors if they didn’t have a ticket. We’ve already seen that this year’s event has a lot more inertia than last year’s did. I do expect we will sell out and recommend buying a ticket ASAP.

Where can I buy a ticket?

Right here.

How can I get the latest news about WordCamp Boulder on Twitter?

Follow @WordCampBoulder

What happened to WordCamp Denver?

We’ve moved it to Boulder this year. There are great tech communities in both Denver and Boulder, it just made sense to have it in Boulder this year since we had it in Denver last year.

Does this mean it will be in Denver next year?

That’s the current thinking, though we are always happy to hear feedback from the community about location, venue, content, etc. for the event. After all, it is an event for the community – we want your help in shaping it.

How can I provide useful feedback to help shape this year’s WordCamp?

We have a survey you can fill out. Also, feel free to get in touch with any thoughts, idea and/or concerns you want to make sure we take into consideration.

I want to help, what can I do?

We can aways use more great volunteers, speakers and sponsors. Please get in touch and we’ll be glad to work with you.

What can you tell me a little about the venue?

We’re going to try something a little different this year. Our main stage will be at the Boulder Theater. This will be the location for morning check in and for the larger presentations. We will also be having smaller discussion and technical sessions at the TechStars Bunker and Atlas Purveyors. We are hoping that the addition of these smaller venues will allow for those some sessions to be more interactive and hands-on.

Is the WiFi going to work this year?

We sure hope so. We can’t promise anything, but we have already taken steps to try and ensure we have great connectivity this year. Also, we should have better cell signal available in these venues.

Will there be a live stream of the event?

Probably not. We do plan to have videos posted on WordPress.tv after the event.

I’m quite looking forward to the event. We learned a great deal last year and received a bunch of valuable feedback – hopefully that will manifest itself in a stellar WordCamp Boulder 2010.

1. Download, install and activate Twitter Tools.
2. Click a link to twitter.com where you would have to register your WordPress site as an application.
3. Take the two keys provided to you and go back to the Twitter Tools settings page. Copy-paste those keys into fields in the Twitter Tools admin page.
4. Click another link to again visit twitter.com, this time to do the OAuth handshake and get your authentication tokens.
5. Return to your WordPress admin and continue tweaking your settings, etc.

If you were able to succeed in these steps, everything would be set up.

The fact that I as a developer look at those steps and groan was an immediate red flag to me. I know all too well from years of email support questions that not all WordPress users are highly technical and a 4 step process with 2 steps that make you change sites and one that includes a copy-paste dance isn’t something that is going to make people happy.

Some people have suggested that this is just how it is and I have to deal with it. I disagree. When I see something that’s too hard I want to fix it, not perpetuate it. I sent an email outlining my concerns to the Twitter API team. They are smart folks, clearly they had been working on solutions for this situation as well. They have posted a proposed outline of a different workflow that looks to be an improvement over the previous situation. It’s an improvement, but it’s not enough.

I added the following to the thread:

This is excellent news and sounds like a much better user experience than the previously discussed options. I would like to suggest it be taken one step further. Could the encoded string with the keys be returned programatically to the Open Source application instead of asking the user to copy/paste? This way the user experience would be very similar to a standard OAuth transaction.

I really hope they make this change and provide the string with the tokens via a callback method/URL and allow us to completely skip the copy-paste step.

I don’t pretend to have thought through every situation that the Twitter API team is having to consider here. I’m focused squarely on my own little use case. My goal is simple: make the process of installing and configuring Twitter Tools as easy as possible for my WordPress users.

With what they have outlined and my suggestion above, I am hopeful that I will be able to support a user experience that looks something like this:

1. Download, install and activate Twitter Tools.
2. Click a button in the WordPress admin that registers your site with twitter.com and returns the necessary tokens to Twitter Tools.
3. Click another link to again visit twitter.com, this time to do the OAuth handshake and get your authentication tokens.
4. Return to your WordPress admin and continue tweaking your settings, etc.

The OAuth step is going to be required – there isn’t a way around that (and shouldn’t be). However I want the rest of the connection stuff should be as painless as possible for my users.

If you care about this, you might want to drop the Twitter API team a line (api@twitter.com or @twitterAPI) and encourage them to go one step further in their proposed implementation so that Twitter Tools can give you the easiest possible configuration experience.

My guess is that the OAuth deadline will be extended while this new API is being implemented and tested. I am currently holding off on my Twitter Tools integration until I see where things end up.

My concern is with the user experience of the initial install and set-up of the plugin. This would take a pretty big hit if I implement OAuth according to my best understanding of the required guidelines. I’m exploring some other options to see if I can find a good way to reduce the required steps and keep a nice simple user experience.

Regardless, I still plan to have something ready for public release before the deadline – though time is getting a little tight.

Ms. Bates, your carefully chosen words say volumes.

Not to confuse people with the facts, but not only does Twitter Tools give you fine grain control over your decision to send (or not send) each post to Twitter, it even has a feature that prevents posts from being tweeted if they were published before you installed Twitter Tools. Could there be a bug? Sure (though it’s unlikely that I wouldn’t have heard about it before now), but that’s not really the point is it?

The “don’t tweet old posts” feature was added in version 1.2b1 back in 2008. It was added solely because people requested it; it certainly wasn’t something I needed – just trying to make things better for the WordPress community.

Of course for every group of people you satisfy by adding a feature, you’ll have an equal number of people requesting the opposite:

The joys of building software and giving it away for free.

The irony of course is that I was getting set to start coding on a rewrite of Twitter Tools this evening (since there is a deadline looming), but comments like the ones above really take the wind out of my sails.

The combination of an evolving set of best-practices in WordPress core and extremely high expectations from the WordPress user community has plugin developers in a tough spot these days.

I hired someone this summer for the sole purpose of updating all of our publicly released plugins/themes from the best practices of the time to the best practices in WP 3.0 (along with a few added features, bug fixes and enhancements). That’s the entire job. I expect it to take about 4-6 months to update the ~30 plugins/themes in question.

That’s an expense I decided we should take on for the good of the community. The cost of the developer’s salary alone is way more than the total donations received on all of the plugins (over a 5-6 year period) – not to mention the time spent creating them in the first place, updating them, etc.

There are many things in the WordPress community that are great. There are also many things that need to continue to evolve and improve.

Enough ranting, I’ll go back to working on something more productive…

No, the real power of custom post types is more subtle – it removes those posts from default queries.

Selecting posts based on certain criteria has always been pretty straightforward in WordPress. What has been hard has been excluding that content from all default queries (home, archives, category, feeds, comment feeds, etc.). By using a custom post type, you can easily exclude content from these default queries, and this is a huge win.

Some people view WordPress as a CMS platform to build on. They want us to help them create a website, service, etc. and they see WordPress as a platform that their idea can be built on. For these projects we will typically use some existing tools for various features but build customized solutions based on the feature set we work to define with the client. The final solution typically has a smooth and cohesive back-end administrative interface and is logically consistent throughout the feature set.

These projects are typically larger engagements and these clients are typically willing to make a larger investment in the development of their project in exchange for a more cohesive, consistent and robust result.

On the other side of the spectrum are people who come to us viewing WordPress (and the thousands of plugins that themes that are available for it) as a product. These folks typically are looking to create a website with a certain feature set and may already have in mind a collection of existing plugins that they think may be useful for creating these features. They expect the project to be more a matter of configuration than development.

These clients are typically primarily interested in keeping costs down and will trade elegance for expedience.

As you might imagine, these two very divergent approaches can lead to some significant challenges, especially when initially talking to potential clients.

The first thing we do is try to figure out which camp a project falls into. Once we know if it’s a platform or product project, everything gets quite a bit easier. This can be much more difficult than you might imagine. Our prospective clients typically see WordPress in only one way, while we can see it from many angles given our extensive experience. A number of clients will describe what sounds like a platform implementation, then all of a sudden they may tell us something that swerves onto the product path. The opposite can also be true. We always try to determine this as early in the process as possible, but we’ve also had rare cases where a project has switched tracks in the middle – I recommend doing all you can to avoid this.

Once we’ve established the type of project involved, we have to do a couple of things:

1. determine if the client’s desired approach will lead to a successful implementation based on their description of the end result
2. do a finger-in-the-air scope to budget check to make sure they are compatible
3. determine if we are comfortable building the project as the client desires (we think it could be a product implementation, but there’s a Twinge…)
4. if we get through all of the aforementioned, create a rough development outline for the purposes of creating an estimate

The first part here is the most important. It’s very important to us that we have a happy client at the end of a project. If we are hearing requirements that all lean towards a platform project but the client is voicing an opinion for a product implementation, that’s a concern. When everyone is on the same page, the chance of missing expectations is greatly reduced.

For example, if a client wants to do a product implementation but has specific functional requirements for various components and is unwilling to relax those requirements based on existing functionality (in WordPress, a plugin, etc.), then we should really be talking about a platform project instead of a product project.

There are also some significant differences in post-launch support and follow-up development with each approach. We will often engage in an ongoing support and maintenance relationship with clients whom we have developed larger platform sites for. These relationships generally run quite smoothly, with requests for additional features and functionality being built incrementally on top of the foundation we built in the initial implementation phase of the project.

Conversely, for the product projects we engage in, it is more typical that we build the site or service and hand it off to the client to run from there. When the client comes back in the future and wants changes made, the ease of implementation and resulting cost of new features can vary widely based on how these new features can be implemented on the wide variance of approaches utilized by the off-the-shelf plugins that provide many of the features for their site. It’s also not uncommon for upgrades to a 3rd party plugin to change certain functionality in such a way that it no longer works exactly as desired for the client’s purposes.

Another challenge with WordPress as a product engagements is managing expectations in regards to 3rd-party plugins and themes. In most cases we will try to budget time to code-review any plugin we include in one of our builds to make sure it is secure and will scale to client’s needs. This can result in us advising the client not to use the plugin or theme they had intended, or require additional time and cost investment in addressing shortcomings of the plugin or theme. There is also the issue of fixing functional bugs in these plugins.

People who view WordPress as a product will typically expect that any collection of plugins will work elegantly and seemlessly together. Rarely is this the case. Even between experienced WordPress developers you will find preferences for different implementation approaches. Mix in plugins written by developers that do not have extensive WordPress experience and you can end up trying to weld the transmission from a 57 Chevy to a tricycle.

The important thing for us from a project perspective is to be honest and consistent with our clients. They may not want to hear than plugin X and plugin Y aren’t going to be compatible, but it’s a lot better to tell them up front than to have to tell them late in the development cycle when you discover that you’ve run out of duct tape.

While you can probably tell from my descriptions here that we prefer to work with WordPress as a platform because we like building elegant solutions. However, we do engage in WordPress as a product projects as well and have built some sites and services we are quite proud of.

WordPress is both a platform and a product – it’s a wonderful and confusing world.

If you’re a WordPress developer or are interested in building something interesting with WordPress, taking a moment to figure out if you need/want to use WordPress as a platform or as a product may save you quite a few headaches.

This plugin gives you the ability to set a collection of file extensions that you do not want WordPress to handle. For example, a request to a .gif file probably isn’t a valid request to one of your posts or pages, so having WordPress look at the URL and try to find something to show is a waste of server resources.

Note that this is a very basic implementation that has been only lightly tested on a few sites. If you have any trouble with it or think an alternate implementation would be an improvement, patches and/or suggestions are quite welcome.

All of my plugins now have new homes on the Crowd Favorite website, along with their own dedicated community support forum. You can find the details, screenshots, support info, etc. for this plugin on the Exclude File Type Requests plugin page.

Enjoy!

I’m looking forward to seeing a number of friends in the community this weekend. Of particular note, I’m hoping to talk to more plugin developers and find our new ways that WordPress HelpCenter can work for them.

If you’re going to be around and would like to catch up or perhaps meet up and get acquainted and talk WordPress – get in touch or come say hi at the event.