Tag Archives: wordpress

OpenID and WordPress Core

This was actually a comment I left on my last post about the v3.3 release of the OpenID plugin. It is a topic that comes up relatively often, and one in which most people are surprised when they hear my stance on it. It’s worthy of a separate discussion for those that are interested, so […]

WordPress OpenID v3.3

I’ve finally gone ahead and released version 3.3 of the WordPress OpenID plugin. This release includes three major sets of changes. First, it drops support for older versions of WordPress… the minimum required version is now 2.8. Trying to maintain backwards compatibility requires a non-trivial amount of effort, and I’d rather spend that time working […]

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 […]

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 […]

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 […]