The whole notion of plugins is that they provide special niche functionality that not every site would need. But that is just theoretical, as most new features that have ever been added to the WordPress core began life as a plugin. If the plugin was useful to enough people, it was built in.

This is something I find myself answering a lot. Excuse the snarky introduction to this post, my real goal here is to attempt to clarify what will and will not “work” with WordPress. So, to answer the question, “will this work With WordPress?!?!”…

Recently, I found myself on the front lines of WordPress’ somewhat complicated Media-Library system. The site that I was developing required a rather elaborate system of retrieving and displaying image attachments. So, using the latest version of WordPress (2.8.3 at the time), I found myself experimenting with as many template tags and custom functions as I could find. After much experimentation, I discovered the perfect solution, and along the way I collected a healthy collection of recipes for displaying image attachments and their various types of associated information.

Breadcrumbs are such a standard design pattern these days I find it surprising there isn’t a build in WordPress function for displaying one. But no matter, that’s what plugins are for. A quick Google search brings up a couple. Yoast has one, so you know that one is pretty good. The other popular one is the NavXT plugin, which I actually used recently on a project and can fully vouch for it.

Hello WordPress peeps! Did you know that WordPress makes it super-easy to display some basic statistics about your database performance? The information may be displayed publicly on your web page, slightly hidden in your source code, or entirely private so only you can see it. There are two basic statistics that are drop-dead easy to include on your pages:

Out of the thousands of plugins available for WordPress, there is one that all WordPress users are familiar with: Hello Dolly. As far as I know, the Hello Dolly plugin was the first WordPress plugin and has been included with every version of WordPress. The plugin is so familiar that many WordPress users don’t even think about it. They either activate the plugin or delete it without giving it a second thought. But if you actually stop to think about it for a moment, the following questions seem inescapable:

I was recently putting together a site where I found it very useful to have a number of small areas of the site as separate chunks of code I could include in templates at will. The site wasn’t unusual at all, it just never occurred to me to get this fine-grained with includes before, but I’m starting to do it now and I like it.

Close monitoring of your site’s PHP errors is crucial to operating a healthy, secure, and well-performing website. When left undetected, PHP errors can reduce performance, waste bandwidth, and leave your site vulnerable to malicious attack. PHP errors usually occur unpredictably and spontaneously, and may be triggered by even the slightest changes to your server configuration, database setup, or WordPress files. Even if your site appears to working properly on the surface, it may in fact be suffering from undetected PHP errors that should be fixed as soon as possible.

I find on nearly every one of the many, many WordPress powered sites I take care of, I have at least a couple of special page templates that I set up and use frequently.

Not everyone loves the post-revisioning feature of WordPress. In fact, some people can’t stand it. On the one hand, it’s nice to have a library of post-draft revisions to drudge through if you should ever make a mistake. On the other hand, multiple copies of every post is a great way to bloat your database with otherwise useless information.

I think you’ll be surprised at how ridiculously easy this is. We are going to leverage some serious smartness from both WordPress and from the JavaScript library jQuery.

In this DigWP tutorial, we take a look at a the potential security risk inherent in displaying your site’s WordPress version number to anyone or anything that happens to stop by for a visit. For anyone who has been working on securing their WP-powered website, one of the most commonly seen security tips around the WordPress-o-Sphere has got to be this:

I usually recommend that people install WordPress at the root directory of their sites. Even if you intend to mostly use WordPress for a blog, and run it at /blog/, you can still do that when WordPress is installed in the root directory. It’s just a matter of changing some simple settings. But just because WordPress is installed and controlling your site from the root directory, that doesn’t mean that the WordPress core files need to be located in that same location.