With Twitter being all the rage, there are plenty of stories out there about how [different businesses are using it][] (and other social websites) to engage customers, boost sales, and provide customer service. One of the well-known early adopters of this kind of customer service is a [lone employee at Comcast][], using the twitter account [@comcastcares][]. So when we had trouble with our Comcast internet connection this past weekend, I tweeted my frustration as my own little experiment and ended up being very pleasantly surprised.
WordPress Plugin Pet Peeve #3: Not being extensible
So this is one that is incredibly easy to implement, and yet goes a really long way in keeping people happy with your plugin. The very reason that WordPress has a [plugin API][] is because they know that different people want different things from their blog. Some people are satisfied with just the core functionality that WordPress provides, but most people want a little more. Perhaps they are using WordPress as a photo blog, and need better support for handling that kind of data. Perhaps they need WordPress to integrate with some other system, or pull in data from elsewhere. Whatever their needs, there is no possible way WordPress could address them all in the core package. And even if they were to try, people have different ideas on how the same feature should be implemented, so there would be no way to please everyone. And unless your plugin is very simple, I can pretty well assure you that some of your users probably want it to do something more than it does today, or do it in a slightly different way.
The very same mechanisms that makes WordPress extensible can be used to make your plugin extensible as well. Most of the time this will mean action and filter hooks. As a plugin author, you are no doubt familiar with how these hooks work, since your plugin is using them to hook into WordPress. But what some newer developers may not realize is just how easy it is to provide your own hooks to extend the functionality of your plugin.
No related posts.
WordPress Plugin Pet Peeve #2: Direct Calls to Plugin Files
This is actually very similar to my first pet peeve of [hardcoding the path to wp-content][pet-peeve-1], in that it makes assumptions about where files are placed on the filesystem. Oftentimes, plugins need to handle certain kinds of requests, maybe for some specific protocol, or to handle an AJAX request. Some plugins will do this by making an HTTP request directly to one of the files in the plugin… something like:
echo '<script type="text/javascript">
jQuery.get("' . plugins_url('my-plugin/ajax-handler.php') . '");
// do something with AJAX data ...
</script>';
This is not a problem in and of itself, in fact it’s great that the plugin developer is actually using the plugins_url function! The problem arises in the my-plugin/ajax-handler.php file itself. Read More
No related posts.
WordPress Plugin Pet Peeve #1: Hardcoding wp-content
Perhaps my biggest pet peeves I run across with WordPress plugins is when developers hardcode the URL or path to the WordPress content folder. By default this folder is named ‘wp-content’, and resides at the root of the primary WordPress folder. However, since WordPress 2.6 (released July 2008), this location [can be moved][] by simply defining a constant in wp-config.php. That’s precisely what I do on my website: my WordPress installation lives at [/wordpress][], while my content folder is at [/wordpress-content][]. I like having this separation of core WordPress files from the themes, plugins, and uploads I’ve added myself. It also makes it easier for me to upgrade WordPress, since I don’t use the built-in upgrade system added in 2.7. Any plugins that still hardcode the path of the wp-content folder break in often spectacular ways on my site.
So what should plugins do instead? In order to make moving your content folder possible, WordPress 2.6 added a number of constants and functions which refer to the correct location of several often used folders. Read More
No related posts.
Directed Identity vs Identifier Select
I initially started writing this post a couple months ago in response to the common misuse of the term “directed identity” I was seeing in the OpenID community. After reading Dirk Balfanz’s guest post “Users vs. Identity Providers in OpenID” on Eran Hammer-Lahav’s blog, I decided it was important to get this posted. I think some people who are relatively new to certain identity concepts genuinely misunderstand what is meant by “directed identity”, while others know the difference but are simply loose with the term. In how it is most often used in the OpenID community, the exact distinction between “directed identity” and other related concepts is not terribly important for now. But as we start seeing OpenID used in higher value transactions, and where higher degrees of privacy are required, not understanding the difference can lead to great confusion.
Read More »
No related posts.