365 Days of WordPress

It's been about a year since I started freelancing, and a year and a half since I started using WordPress to content-manage my site and the websites of my clients, so I thought it's about time to give back to the WordPress community and the many coders and blogs out there I've borrowed from over time.

Why WordPress?

For the uninitiated: WordPress is really a PHP application for bloggers. The application is a set of PHP templates that pull data from a MySQL database. It's simple, it's intuitive, and it's easy to set up for those who don't spend 95% of their time coding for a living. But it's not really a content management system, and doesn't pretend to be. So why do we developers insist on forcing WordPress to act like one? We like tricking-out our WordPress installations because the platform is so open to being amended, and also because it's a great intermediary between a "real" CMS like Drupal or Joomla and no CMS at all, for those of us who aren't quite programmers.

The Pros and Cons of WordPress

There has already been a lot of discussion out there about the pros and cons of using WordPress as a CMS for small-scale sites and self-hosted blogs. Given the number of users who do use WordPress in this way, it's safe to say that WordPress is a good thing, and is worth using. Of course, consensus is never a good reason, in and of itself, to be on board with any new service (see Twitter), so below I've summarized popular opinion on the matter:

Pros

1. WordPress is open source and standards compliant out-of-box. The power of the open source community, I believe, is invariably stronger and more devoted to producing a quality product than the power of a commercial entity. Open source allows for more manpower, more self-criticism, and a broader vision of the future than a closed-source project.
2. The WordPress community. When you use WordPress, you can turn to the WordPress community for reference and support. And I don't mean just WordPress.org. I've been able to find a solution (or enough discussion about a problem to find my own solution) to almost every quandary I've faced simply by googling functions, because WordPress is used by millions of people worldwide.
3. WordPress is extremely extensible. For those of us who aren't programmers, WordPress plugins are a wonderful thing. There are hundreds of useful plugins in WordPress' plugin directory that can extend the base functionality of the platform and really make WordPress powerful. Caveat emptor, of course, because some plugins do have a tendency to bloat WordPress installations (or render them insecure). Nevertheless, the community is usually on top of finding security flaws in popular plugins and/or coming up with hacks for (or completely assuming responsibility over the development of) plugins whose developers have abandoned them. The sky's the limit.

Cons

1. Not for the technically challenged. Without a doubt, a self-hosted WordPress blog has a learning curve. If you don't know PHP well enough to tinker with the WordPress templates, you won't be able to do any customization outside of plugins and themes.
2. WordPress is a resource hog. I won't entertain arguments programmers make along the lines of "PHP sucks as a programming language, therefore WordPress sucks" (because their beef in this case is with PHP, not WordPress), but we must concede that if you're building a large website with WordPress, you have to be very careful how you set it up. Put quite simply, WordPress has to query the database too frequently to construct each page, and so the whole system has the potential to collapse if it's hit with a significant amount of traffic. One infamous example is "The Digg Effect," which is what happens to a WordPress blog when it piques the interest of Digg users. There are ways to mitigate these effects, however—tweaking settings in MySQL and/or using a query cache—and installing plugins like WP Super Cache to serve static html instead of dynamic pages to anonymous users.
3. The goddamned text editor. Because WordPress was designed for non-technical users, the WordPress text editor can be a real pain in the ass if you want to enter anything other than text. The text editor does its best to automatically line-break and sanitize your input, so that what gets dumped into the template is nicely formatted in paragraph tags. Even though the text editor has an HTML input option, WordPress will still rewrite your HTML to its liking. This quickly becomes extremely frustrating. The only way around the wpautop function is to disable it with a plugin (which results in other issues and the complete loss of auto-formatting), or to modify the WordPress core, which is a no-no for our purposes. In the end, the best solution to dealing with the text editor is to design your templates such that your users won't be expected to enter anything into the text editor that isn't text or images. That way, WordPress is happy and you have happy users. Use custom fields for everything else.
4. New releases and old plugins. The WordPress developers release new versions of the platform frequently. The latest version of WordPress has an Automatic Upgrade feature built into the core, but the problem lies not so much between the platform and new versions, but between new versions of the platform and outdated plugins. Plugin developers are third parties who contribute to WordPress for free, so they aren't releasing updates on the same schedule as the WordPress team. You often have scenarios where your favorite plugin isn't compatible with the newest release of WordPress, and you rely on your plugin for some major functionality in your installation. And if this is the case, you probably don't have the programming knowledge to update the plugin yourself, so you're stuck waiting until the plugin developer gets around to making the plugin compatible with the new version of WordPress (if ever). In turn, you decide not to update WordPress. Scenarios like these contribute to the vast wasteland of vulnerable, out-of-date WordPress installations that pollutes the internet.

A Few Ground Rules

Before I embark on this series, I want to put a few ground rules in place. These are my basic assumptions going forward. I may add assumptions from time to time, so check back here before you chew me out.

1. Not for WordPress gurus. First of all, I'm no programmer. I work as a front-end CSS/HTML developer, but I have enough knowledge of PHP to get by with WordPress. Part of the reason why I use WordPress is because I simply don't have the mind to do real programming. I'm sure there are better ways to go about doing some of the things I'll show you, and I encourage you to show me how we can benefit from more efficient code, but don't be an asshole. The people who'll be reading this series need help, not snark.
2. Skills you'll need. I'm assuming that you're comfortable writing PHP and have an intermediate knowledge of CSS and HTML. You should also not be afraid to open your MySQL database in phpMyAdmin.  While there'll be a lot to copypaste, this series is not for copypasters.
3. Standards are everything. Everything we write has to be standards compliant. Compliant websites are easier to make cross-browser compatible and easier for spiders to crawl. I grant you that a lot of large, functioning sites are not standards-compliant and have been trotting along just fine. Google is not standards compliant, for example. But then again, Google has the clout to flout standards. Google creates standards. For you and I, that means we adhere to XHTML Strict 1.0. (Also, we will stick to CSS 2.0 as long as we have to. Support for the 3.0 specification is sketchy at best.)
4. We won't touch the core. We won't touch the core WordPress files in all but maybe one example. There's really no reason to modify the core, especially since the WordPress Team releases new versions on a fairly regular basis, and modifying the core would create problems when you update the application. The same won't apply to plugins, however. Plugin developers are cool people, because they do the hard work for us (and for free), but there will be cases where we'll have to muck around inside a plugin to make it do what we want to do.
5. We'll support all the modern browsers. As of March 2009, w3cschools indicates that the breakdown for browser usage statistics is as follows:
   1. Internet Explorer 6: 17%
   2. Internet Explorer 7: 24.9%
   3. Internet Explorer 8: 1.4%
   4. Mozilla Firefox: 46.5%
   5. Google Chrome: 4.2%
   6. Safari: 3.1%
   7. Opera: 2.3%
   • Until Internet Explorer 6 drops below 1% in browser usage, we'll still have to support it. Any browser that breaks 2% we'll keep an eye on (Internet Explorer 8 is an exception, because we know that browser will eventually get widely adopted because of Windows 7, so we might as well prepare ourselves for the inevitable). I know, I know—I hear your groaning. Part of what's contributing to that high figure for IE6 is those of us developers who continue to support the dinosaur. But the problem is that the percentage represents not just standards-flouting buffoons who refuse to update their browsers, but legitimate users like the elderly, the disabled, and employees of government or educational institutions whose networks prevent them from updating their browsers on their own.
6. Resolution. Our target screen resolution is 1024x768.
7. Accessibility. We'll try our best to meet Priority 1.

So with that, I'll see you tomorrow.

• Comment |
• Email |
• Trackback |
• Share |
• Print

Your Comments