We’re looking for someone with a broad range of WordPress, PHP, XHTML and CSS experience, basic server configuration experience, and in particular someone with outstanding communication skills.

Ideally we’d like to add someone who lives on the west end of the country¹ in order to have better coverage throughout the work day across all US timezones. However, we’re definitely looking for the best person for the job.

Providing great service is our number one priority, and we need someone who understands this inherently. Not only does the HelpCenter team reflect on Crowd Favorite, but we also have a responsibility to every affiliate plugin and theme developer who puts their trust in us. It’s also important to continue receiving good press and word-of-mouth recommendations.

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

Questions? Post them in the comments and I’ll try to answer.

1. You can work remotely. [back]

This release addresses two bugs:

1. The use of the native json_decode() function, required by the changes in WordPress 2.9 (version 2.1) created a problem for users with servers running 32-bit PHP. The json_decode() function treats the tweet ID field as an integer larger than it can handle, which causes the issues. Thanks to Joe Tortuga and Ciaran Walsh for sending in the fix. Of note: I haven’t had a chance to set up a 32-bit PHP install so I can’t reproduce this, but it appears to work for many based on forum feedback. Yep, I’m still dealing with the ramifications from this.
2. Typo-fix that should allow resetting digests properly (not sure when this broke). Thanks lionel_chollet.

The download and more information are available on my WordPress Plugins page.

If you have any trouble with this, please contact the WordPress HelpCenter (303-395-1346) or you can try the WP Support Forums.

Sure it was frustrating. I was in a situation where there was a bit of public outcry about my plugin being “broken”. All of a sudden, something that used to work fine didn’t (for some). The result? I spent a good deal of time debugging an issue with my plugin that I didn’t cause and couldn’t reproduce.¹ However when you step back and look at the situation, I’m not sure there is a clear-cut target to blame here. Everyone’s intentions were pure. The point is, this is an interesting case study and one that both the WP plugin and theme devs and the WP Core devs can learn from.

Situation

Versions of PHP prior to 5.2 do not include native functions for encoding and decoding JSON formatted data.

The solution in Twitter Tools prior to the releases last weekend: include a PHP library (Services_JSON) along with the plugin, wrap it in a check to make sure that it isn’t already included, and use it instead of the native PHP functions.

The solution in WordPress 2.9: define the equivalent versions of the native PHP encode and decode functions in the core, include a PHP library (Services_JSON) in those functions and load it if needed.

So we had a situation in some WordPress server configurations where my plugin loaded the library, then WP core tried to load the same library and PHP didn’t like that very much.

The WP 2.9 solution provides us with an interesting situation. I still wanted to support versions of WP prior to 2.9, which means I still need to include my copy of the library. However I also don’t want it to break in 2.9, so I need to make my inclusion of the library compatible with the WP 2.9 approach.

Solution

Use the same approach in my plugin that WP 2.9 does. WP 2.9 checks to see if the PHP function json_encode(), etc. exists, and defines it if it doesn’t. If Twitter Tools does the same thing and loads after the WP version (which is loaded from compat.php), it will only define those functions and include the library as needed. Based on feedback, this approach is working for both pre-2.9 versions of WordPress and WP 2.9.x.

Lessons

Plugin/theme devs, be careful when including a compatibility library that might get added to WP core in the future. Try to structure your code in such a way that it will continue to work even if this happens.

WP core devs, when adding a library consider the plugins that might already be including that library and do so in a way that lets everything continue to work.

Why wasn’t this caught in beta testing of WordPress 2.9? It’s pretty simple – even though I tested some of my plugins in pre-releases of 2.9, I did not test them with older versions of PHP (required to trigger this bug). I’m guessing that most of the developers that were beta testing were also running new versions of PHP. A true application testing matrix is not realistic for WordPress + plugins + themes.

Take a look at the diff for an example, I think this technique is portable to other plugins that may experience this same problem.

Also, I created a ticket in Trac to try to make this work a little more smoothly going forward. Thanks to the core team for accepting the patch.

1. Trying to patch a problem that you can’t reproduce will inevitably require a few point release. [back]

# | Visit Site »

This version has a bunch of changes including a fix for the issues with WordPress 2.9 and PHP < 5.2.

The download and more information are available on my WordPress Plugins page.

If you have any trouble with this, please contact the WordPress HelpCenter (303-395-1346) or you can try the WP Support Forums.

Enjoy!

Changes

• Add a shortcode to display recent tweets
• Change how Services_JSON is included to be compatible with changes in WP 2.9 and PHP < 5.2
• Better RegEx for username and hashtag linking
• Exclude replies in aktt_latest_tweet() function (if option selected)
• Digest functionality is marked as experimental, they need to be fundamentally rewritten to avoid race conditions experienced by some users
• Make install code a little smarter
• Add unique index on tweet ID columns, remove duplicates and optimize table
• Track the currently installed version for easier upgrades in the future
• Add action on Update Tweets (aktt_update_tweets)
• Use standard meta boxes (not backwards compatible) for post screen settings
• Use site_url() and admin_url(), losing backward compatibility but gaining SSL compatibility
• Added WordPress HelpCenter contact info to settings page
• Misc code cleanup and bug fixes
• Added language dir and .pot file

Bit.ly plugin

• Added a trim() on the API Key for people that struggle with copy/paste
• Changed RegEx for finding URLs in tweet content (thanks Porter Maus)
• Added a j.mp option
• Cleaned up the settings form
• Use admin_url(), losing backward compatibility but gaining SSL compatibility

Exclude Category plugin

• Use admin_url(), losing backward compatibility but gaining SSL compatibility

Hashtags plugin

• Use admin_url(), losing backward compatibility but gaining SSL compatibility

Plugins

In version 2.0 I added the ability for Twitter Tools to be extended via plugins and created the plugins included in the default plugin. Other folks are creating plugins for Twitter Tools as well. You can find more Twitter Tools plugins here.

Have you created a plugin for Twitter Tools? Let me know so I can add it to the list.

I have a new version available that may address the issue that some people were having saving posts with Twitter Tools enabled in WordPress 2.9.

I believe the cause of this issue is as described in this ticket. Basically, a change in WordPress core in 2.9 was incompatible with some plugins that included the same JSON library.

I have not been able to fully test this and would like your help in doing so. If you have experienced these problems, please download this testing version, and let me know your results in the comments. Thanks!

UPDATE: Get version 2.1.x which has the same fix.

First, a high level summary:

• Upgrade immediately. Always. No exceptions.
• Have a development/staging copy of your site to test upgrades on before upgrading your live web site.
• Do check out your copy of WordPress from SVN (use the current branch) on your production web site.
• Do not run a production web site on WordPress SVN trunk.
• Backups are critical (snapshot backups highly recommended); they are your best defense against security issues and upgrade problems.

Ok, now for the detailed discussion…

Security

WordPress security has been a hot-button topic this year. The security vulnerabilities that surfaced in WordPress releases last year were unfortunate, but some were due in part to a systematic approach to try to improve security in WordPress by standardizing how security functions work throughout the code base.

I’ve seen comments that WordPress doesn’t care about security; I think that’s an ignorant statement. The WordPress developers I know care deeply about the quality of WordPress and are constantly working to improve it.

Historical security is not (necessarily) a good indicator of future security.

While I do believe “those that do not learn from history are doomed to repeat it”, I do not believe that you can accurately predict future security concerns based on the security bugs in the past. In Open Source there is the additional issue of new developers bringing new coding styles and blind spots along with their code contributions. Open Source requires everyone to be diligent for security issues. It’s a battle you must always fight, but will never win.

A quick note about the WordPress codebase: it’s important to consider where WordPress came from. The WordPress codebase isn’t architecturally elegant, but it’s improving with every release. The codebase was initially inherited from b2, and certain development approaches and code paths from that code (written back in 2001-2002) are still present today (for compatibility reasons). I’ve been impressed over the last few years how certain backward compatibility features have been maintained while the underlying code has been completely gutted and rewritten. That’s not easy.

I haven’t spoken to anyone on the core dev team about this yet, but I think that the 3.0 release (WP – WPMU merge) is probably the right time to break a few things in favor of consistency for the future. I’m sure that’s a discussion that is already taking place.

Here are some simple tips that may help with security going forward:

• The best way to be hacker-proof is to upgrade immediately and have great backups (more on backups later).
• Turn off features you don’t need or use. This includes user registration, XML-RPC, etc.
• Use only the plugins you need, and consider the source when adding any feature (plugin or theme) to your site.
• Remove plugins and themes that are not active.
• Add 401 authentication to your wp-admin directory.
• Use SSL when connecting to your admin interface.²

Upgrades

New features bring new bugs, and some of those will undoubtedly have security ramifications. The best way to combat this is to upgrade immediately when a new version is available. I upgraded four WordPress installs in three minutes this morning – it’s easy if you set them up right.

The approach I use won’t work for everyone as it relies on developer tools that not all WordPress users are familiar or comfortable with. If Subversion (SVN) is meaningless or scary to you, I recommend sticking with the auto-upgrade or working with someone who can provide the appropriate technical skills to use the approach outlined here (the WordPress HelpCenter is a great option for this).

The WordPress codebase is hosted in a publicly accessible SVN repository – you want to use that. The SVN repository is organized in a traditional manner providing us with a variety of options for what code we want to use.

I recommend checking out the current branch of WordPress and using that for your web site. The benefit of using a branch is that you can simply svn up to update to the latest patch release. If you replace the plugins and themes directories with your own SVN checkouts (as I do on some sites), you will want to use a more selective command for your update:

svn up *.php wp-admin/ wp-includes/

That will get you all the latest code, without affecting the wp-content directories (plugins and themes). Branches are pretty safe – typically the only changes in a branch are to apply the bug fixes and security patches that comprise the point releases for that branch.

If you want to automate your updates using CRON to pull from SVN, this is the process I recommend.

Some folks advocate using tags (the official WordPress releases) exclusively. There is certainly an argument for this, however the svn switch command used to change between tags (and branches, for major releases) is not as easy as the update command on a branch (especially if you’re replacing versioned directories like wp-content/plugins and wp-content/themes in your checkout).

I’ve seen other people advocate running on trunk. This is madness! Trunk is where new bugs and security vulnerabilities are written – you do not want to be running trunk. We’ve been having data loss issues¹ on an internal site of ours that currently runs on trunk.

I strongly recommend that any upgrade be tested on a development or local environment before performing the upgrade on your live web site. The importance of this varies from site to site, but if you’re running a significant site on WordPress (like some of the ones we’ve built at Crowd Favorite), you can’t afford to have your site down because some change in the new release introduces an incompatibility with your configuration or custom code.

So that takes care of upgrading WordPress, what about plugins and themes? It’s true that some WordPress upgrades will break plugins and themes. However, that doesn’t mean you shouldn’t upgrade. If a plugin or theme breaks, you should contact the developer and see if they plan to upgrade the plugin or theme. If they don’t, you may be able to bribe them. If they still won’t, you can see if someone else will do it, or move on. No plugin or theme is more important than your site’s security.

Having a good, deep knowledge of how WordPress works and interacting with it in the proper way will allow you to write plugins and themes that hum along smoothly after a WordPress upgrade in most instances, but you should still test in a non-critical environment.

It’s important to note the position that plugin and theme developers are in with WordPress upgrades as well. When a plugin or theme breaks in a new version of WordPress, it’s not always the developer’s fault. Sometimes a plugin or theme is poorly written and does not follow WordPress coding standards – sometimes the standards that are to be followed are more recent than the plugin or theme in question. The recent change to how widgets are to be coded is a great example. The best practices are constantly evolving, and it can be a challenge to keep up with them all.

I currently have 28 plugins and 3 themes registered on wordpress.org. When a new version of WordPress is released, it’s a tall order to test and patch all of these. There are typically 4 major WordPress releases scheduled each year.

If I did a full test and patch cycle (1/3 day-1 day each) of every plugin and theme I have released with every major release, I’d be spending 4 months a year just testing and patching my plugins and themes.

That isn’t something I’m in position to do, and other plugin and theme developers are in similar positions (to varying degrees).

Additionally, the plugin and theme system of WordPress is in essence a security feature as well. Because of the ability to customize WordPress without making modifications to the core codebase, you can upgrade without having to go through and apply all of your modifications to the new codebase.

Backups

In the event your site is hacked or an upgrade goes south (or really if anything bad happens), your best defense is having great backups.

RSYNC is a great tool, but if you are using RSYNC exclusively for your backups it’s likely you aren’t doing enough. RSYNC will keep a mirror copy of whatever you tell it to back up – this means that if something bad happens on your site, the same thing will be mirrored to your RSYNC backup. There are a bunch of ways to mitigate this – if you are a do-it-yourselfer you are likely already brainstorming a few decent work-arounds. Almost all of these break down if the hack is undetected for a long period of time (a week or two) as staggered RSYNC solutions don’t typically extend that long.

I think the best solution is snapshot backups, going back a reasonable amount of time into the past. This will allow you to pick a known, good point in time to revert to. Test locally, and restore your production site.

During a recent security upgrade rush at WordPress HelpCenter we discovered that many people who thought they had good backups from their hosting providers, didn’t. It’s important that your backups are both monitored and verified for integrity.

Recovery time is important as well. You want a system that allows you (or your recovery team) to get your backups up and running again quickly. Speed is a big issue when your site is down, and having to apply differential backups to do a restore can be very time consuming.

We created BackupMoxie because we needed a service that worked this way for our clients at Crowd Favorite. If you are interested in offering BackupMoxie as a service to your clients, I’ve got good news for you. Next week we are officially launching it as a white label service.

Conclusion

Hopefully this (lengthy) discussion has been helpful for some of you.

In thinking about these issues and in the development my team and I have done over the last few years, I’ve considered a number of ideas that I think could be helpful to the WordPress community. I’m working on an outline for an idea that I think may have some merit for a follow-up post.

1. Still need to try to debug them and submit a patch, actually. [back]
2. Support for this is relatively recent, not all plugins and themes (including mine) support this properly yet. [back]

I’d love to gather some explicit bug reports (this thing breaks here, this code on line X appears to fail, works with all other plugins turned off but not with plugin Y enabled as well, etc.) and/oor access (both WP admin and file editing) to an environment where this is breaking consistently with WP 2.9 and previously worked with WP 2.8.x.

If you use Twitter Tools, could you take a moment to vote if it works for you with WordPress 2.9?¹

Thanks in advance.

UPDATE: Interesting – when I posted this the vote was 12 working vs. 17 broken. The current vote is now 31 working to 20 broken. So far since I posted this another 22 votes have been cast and 19 of them indicate it is working. This seems to be far from a widespread issue, which probably helps explain why no one I know can reproduce it.

1. I realize that this type of call to action will by nature result in more unhapy voters (more “broken” votes) than otherwise – this is the nature of such things. [back]

I’ve got a lot of sites to upgrade – I’ll have a little more on the process I use for this in a follow-up post.

If you need help with your upgrade, our team at WordPress HelpCenter is available and happy to help. Give us a call: (303) 395-1346 or email help@wphelpcenter.com.

We have a:

• new phone number¹: (303) 395-1346
• and new hours: 9am-5pm US/Pacific

as well.

While we are continuing to focus on providing top notch support and customer service for the community, we have added more development experience on the day-to-day team. This allows us to provide expanded on-demand development and customization services as well as offering support and troubleshooting services.

I’d also like to thank all of the plugin developers, theme authors and other affiliates that are working with us – we really appreciate your partnership. If you create plugins and/or themes for WordPress, be sure to sign up for our affiliate program and register them with us so we can give you a little reward when we work with something you’ve built.

1. The old number will continue to work for a few months. [back]

We discussed the WordPress HelpCenter, the Carrington CMS theme framework and a little about Open Source business models.

You can download the MP3 file here.

# | Visit Site »

I think there are a lot of very interesting things to cover about the new affiliate program from the WordPress HelpCenter, monetization and supporting the WordPress development community. So far it looks like some folks would like to hear about Carrington as well – I’ll be happy to try cover that as well.

Feel free to post questions in the comments here if you like and I’ll pass them along.

Affiliate Program

The affiliate program is really core to how we want the HelpCenter to work (note: anyone can join the affiliate program). It creates a formal relationship between WPHC and plugin and theme authors so that we can support the great WordPress development community. It sets up:

• WPHC to pay plugin and theme authors when we do paid work with plugins or themes they created.
• Makes it easy for plugin and theme authors give us FAQs and tips about the things they have built so that we can provide great support for them.
• Builds relationships with plugin and theme authors so we can send them bug reports and contact them with advanced issues we are dealing with.
• Rewards affiliates for referring business to us.

We have a collection of badges that plugin and theme authors can place on their web sites and in the WordPress admin pages for their plugins and themes to direct people to the WordPress HelpCenter to get support (and earn affiliate payments).

We also have released a WordPress plugin that does two things:

1. it adds a WordPress HelpCenter support tab to the admin interface to make it easy for people to contact WPHC for support.
2. It creates a system profile that details key information about a WordPress installation that is very useful in troubleshooting and debugging. This system profile can be sent to WordPress HelpCenter.

Affiliates can download a customized version of this plugin that includes their affiliate code so that they receive a referral payment in addition to any payments for work we do with plugins and themes they have registered with us.

We think that this may be something that plugin and theme authors may want to distribute along with their work. Additionally, developers that create WordPress powered sites but may not be in position to provide on-call support for them may want to install this on sites they create for their clients.

The system profile page created by the plugin uses standard WordPress filters to enable plugin and theme authors to add information to it that may be relevant for their plugins or themes.

I’m really excited about the affiliate program because it provides a monetary reward for plugin and theme developers while actually removing a burden from them and potentially freeing them up to spend more time building great things for the WordPress community.

Over the years I’ve thought and brainstormed quite a bit about ways to provide financial incentives for WordPress developers. Our affiliate program is a start. It’s a true win-win arrangement, and it will only get better as the WordPress community continues to grow.

Public Knowledge Base

The public knowledge base is another core element to WPHC and our vision of what we want it to be. We do troubleshooting and debugging of WordPress, plugin and theme issues every day, and this gives us a way to share the solutions we find with the community.

In addition to our own notes, when affiliates register plugins and themes with us they have the opportunity to add FAQs and tips about those plugins and themes. As appropriate, we then make that information publicly available.

Even better, the affiliates can come back and add additional FAQs and tips at any time. This is something I’m really excited about because the way that plugin README files work, they always lag one release behind on wordpress.org.

We have a section on the site for plugins and for themes. There are a few resources up there now, I’m looking forward to watching these areas grow in the future as more affiliates sign up and register their plugins and themes with us.

I expect this to become a very useful resource for the WordPress community; one that grows nicely over time.

I view the WPHC from several different perspectives.

• As the founder and a partner in the business, I want it to be financially viable so that we can maintain a great staff and provide top notch service.
• As a WordPress professional, I need it to be a place I trust and feel comfortable referring my clients to for support.
• As a WordPress developer, I want users of my plugins and themes to be able to get great support. I also know that with the growth of the WordPress community and the responsibilities I currently enjoy, I am no longer in a position to provide that support directly.

From all of these perspectives, it is of paramount importance to me that the WordPress HelpCenter be a shining and trusted member of the WordPress community. The team and I are very committed to making that happen.

If we are able to continue to build it as we envision, the WordPress HelpCenter will be a great asset to the entire WordPress community. With these new features, I believe we’ve taken a few big steps in that direction.

1. A flood of comment spam
2. Akismet not accepting connections from my server¹ and/or not catching the spam. UPDATE: this wasn’t Akismet’s fault, see bottom of post.
3. The email notifications from all the spam comments sending to my mail account
4. My mail host started blocking all mail from my server (due to the high volume of comment spam)

This has presented me with a choice between receiving email and accepting comments on this site, and that’s an easy choice.

I disabled comments, and once the flow of spam mails stopped my mail host seems to be accepting mail again. It’s sad to see the problems caused by comment spam extending beyond the annoyance of having them appear on your blog.²

I’m taking some additional steps to try to get the mail situation set up a little better (domain migration so I have better DNS control, sending mail directly to Google Apps and then forwarding to my primary mail account from there). I’m hopeful that I can get the Akismet connection issues resolved and enable comments again in the near future.

Regardless, it’s been a genuine pain in the arse having to deal with this. Apologies for the impact it’s had on anyone looking to comment here and/or receiving emails from my server.

UPDATE: re-enabling comments, hoping for the best.

UPDATE #2: the inability to reach Akismet appears to have been due to a firewall issue on my server (no blame should be placed on Akismet).

1. It allows connections at times, but then doesn’t for long periods of time. [back]
2. They can also cause server scalability issues. [back]

This will be a full time position with benefits, and we are open to remote candidates. See the job posting on the HelpCenter web site for more details and to apply.