Templating

WordPress offers a templating system for implementing custom HTML and CSS, but it is not a templating system in the same sense as Smarty (http://www.smarty.net) or Perl's Template Toolkit. Instead, like many PHP CMSs (most notably Drupal and Joomla!), WordPress templates are simply PHP files that typically contain a mix of application logic and presentation code, for example, <div id="footer"><?php wp_footer(); ?></div>.

Compare that with a Drupal template excerpt: <div id="footer"><?php print render($page['footer']); ?></div> or with a MODx excerpt using Smarty placeholders: <div id="footer">[[*footer]]</div> and you can get some idea of the spectrum. Typically, the templates used in WordPress do not adhere to the Model-View-Controller (MVC) pattern, so they cause some developers to raise a critical eyebrow.

Be aware that your WordPress templates contain PHP code and that they do execute, so it is naturally possible to "crash" your templates, or to have complex loops and logical statements in them. As a developer, try your absolute best to separate logic from presentation and keep your templates as clean as possible. There are plenty of WordPress theme files out there that contain a dizzying mess of PHP and HTML, which result in an unmaintainable no man's land. Designers won't touch them because they can't decipher the myriad if-statements and sloppy concatenations, and developers won't touch them for the same reason, or perhaps because they contain HTML and CSS that developers don't want to worry about. In the end, just try to avoid the numerous pitfalls that exist in this type of templating system.

Introducing plugins

Like any good CMS, WordPress offers an application programming interface (API) for developers to perform common tasks in their plugins. Unlike many CMSs, however, the WordPress API is largely procedural: it exists mostly as a series of globally scoped functions and variables in the main namespace, so you have to be extra careful when naming your functions to avoid naming collisions. There are certain tasks that are object oriented (OO), but there is a decent chance that you could look through a dozen WordPress plugins before encountering a class or an object. In certain programming languages, such an arrangement is unusual if not impossible, but the PHP community in particular often offers procedural equivalents of object-oriented code.

Opening up an existing WordPress plugin is a bit like going into a public restroom: it may be perfectly clean and hygienic, or it may be a rank and apoplectic mess of functions, logic, and HTML. Just be prepared.

WordPress plugins use an event-driven architecture—anyone who has seen a JavaScript function triggered via an HTML "onClick" is familiar with this approach, but in WordPress, the events are typically referred to as hooks. A hook is an event—it is a place where you can attach (or "hook") code. While examining existing plugins, keep an eye out for the add_action() and add_filter() functions that tie a hook to a function inside the plugin. Depending on the author, add_action() and add_filter() instances may be scattered throughout the code or consolidated into one place.

The number of hooks available in WordPress has been steadily increasing and with version 3, there are well over 1,000. Unfortunately, they are not well documented. This daunting number represents an unwieldy weak point in the WordPress architecture. How can the developer find the one or two he needs? We have included a list of some of the most common hooks in an appendix at the end of this book.

Many plugins contain convoluted mixtures of logic and HTML within a single function. This scenario is unfortunately common in many PHP CMSs, and it can make it exceedingly difficult to find and fix formatting errors. You may be fighting an uphill battle, but we strongly recommend separating your plugin logic from any formatting code. It will make your plugins easier to maintain and skin.

Another thing to remember when writing plugins is that WordPress 3.1 is the last version of WordPress that is compatible with a dwindling number of PHP 4 users. Be sure your plugin tests the PHP version in use, especially if you use the more advanced language constructs available in PHP 5.