Before I get into the guts of WordPress 3.4, I want to point you to a resource which highlights some of the thinking that is going into the development, now and in the future, of how WordPress is built. Andrew Nacin sent an email to the “hackers” mailing list discussing object-oriented development that informs the thinking of the core developers now that WordPress supports PHP 5.2 and true object-oriented programming.

While it may be over the head of non-developer types, the gist is that now that we (used loosely) can write code smarter, we’re working our way in that direction. Some of the code in WordPress has existed for “generations” of versions and is bulky and inefficient. With new tools at our fingertips, we can begin to approach the idea of refactoring some of this code in better ways. Backwards compatibility is always retained, however, in 99 out of 100 times. WE ARE NOT DRUPAL!

Without further adieu, however, let’s get into what you can expect in the new version of WordPress.

Embed Tweets with oEmbed

Since version 2.9, WordPress has supported a technology called oEmbed that, simply put, has allowed the inclusion of rich media in content in a very simple way. Simply paste a YouTube link on a new line, and WordPress turns it into a properly sized video. No embed code needed. Same for Vimeo, Flickr, Scribd and more. The entire list can be found on the Codex. Now, however, Twitter is supported. Simply place the URL of a tweet on it’s own line and… bam, you have this:

Twitter is an oEmbed provider that is supported out of the box in WordPress 3.4

— Aaron Brazell (@technosailor) May 23, 2012

Query Efficiency Improvements

The common bottleneck for all WordPress users are database queries and data “munging”… that is, what WordPress does with data when it’s returned from the database. The query that brings in all the necessary content necessary to render a page used to look like this:

This has been how the query has worked for years. Really since the beginning of WordPress. And while, in theory that works (and it does, again it has for years), the core reality of this approach is that all the data in the posts table matching the criteria in the WHERE clause is more data than is needed, thus causing potential performance problems.

The new approach is simple and elegant. The first database query simply fetches a list of post IDs that fit the criteria provided in the WHERE clause.

This approach means the amount of data in memory and floating around WordPress is concise and compact. PHP doesn’t have to work harder to traverse arrays or objects… it is simply a smaller list of data.

But what about the other data? We need the other data! Yes, in fact we do. But since WordPress has an object cache, much of this data is in the object cache. We don’t need to retrieve it from the database.

The second step is to look to the object cache for posts with IDs matching any of the IDs in the first dataset. Anything we can’t find is followed with a second query to get all the information matching the non-matched IDs using MySQL’s IN() function:

By changing how SQL and object caching is used, WordPress 3.4 finds new efficiencies. In the original ticket, developers were observing 2-3x speed performance improvements. I’ll drink to that.

Theme Customizer

Non-technical WordPress users will love the new Theme Customizer. Otto has a great write-up on this new feature. His video is above. The key takeaway from this new feature is that is possible now to customize a great number of things in a theme  from right within WordPress. On the fly. with a live preview.

Change your title, tagline, background color, image and more with a click of a mouse. I can see this being used to create child themes in the future, but for now, it manages settings that are already in WordPress (and accessible in other areas of the WordPress Admin) on the fly. The best way to really appreciate this feature is via Otto’s video above. Related: The best way to leverage this as theme developers is outlined in great detail in his post…

Bundled ‘Touch’ Support

We live in a touchy-feeley world. And by that, I mean mobile. Specifically iOS and Android. In WordPress 3.3, we saw adaptive design come to portions of WordPress. Adaptive design, for the uninitiated, is a technology that elegantly resizes a website to adapt to the the screen it is rendered on. It is a way for developers to create a single experience that works on desktop/laptop browsers as well as mobile interfaces with arbitrary resolutions.

As mobile continues to lead the charge in today’s web, WordPress 3.4 has bundled the jQuery UI Touch Punch library that will give front-end developers more tools to work with in making a website mobile-friendly. Simply include the library via wp_enqueue_script() and now your element has the .draggable() method available. This method enables “drag and drop” support that was previously unavailable and the one major caveat is that it does not support Windows 7/7.5 phones due to limitations in the IE9 browser.

HTML in Captions

Photo by Kyle McCluer and used under Creative Commons. Some Rights Reserved.

I’m trying to rotate between developer tools and user tools in this article, so at this time, I’d like to point out a simple yet important frustration in previous versions of WordPress. When you upload an image and use the media uploader to then insert an image, you have the option of writing a caption. Sadly, it was impossible to include HTML in previous WordPress versions.

Often times, linking the source of a photo is welcome and, possibly depending on the usage restrictions on a photo, required. Before, the only way to do that was to set a link in the media uploader and then the photo would be linked. Now, in WordPress 3.4, you can include basic HTML in your captions as I have done above.

XML-RPC Improvements

XML-RPC. The thing that allows the WordPress apps for Android, BlackBerry and iOS to function. The thing that allows offline editors to function by remotely communicating with WordPress through a public-facing API.

XML-RPC is a venerable technology that is based mainly on the Metaweblog API invented a decade ago. WordPress has supported this iteration of XML-RPC as well as the Movable Type XML-RPC and Blogger XML-RPC APIs for a long, long time. However, WordPress has also extended the Metaweblog API and added it’s own methods along the way.

No more. Instead of band-aiding a solution on top of a limited set of methods intended for blogging only, WordPress 3.4 includes a brand new WordPress XML-RPC API designed to support all the rich features that have evolved since WordPress started focusing on CMS-style features. It incorporates all the methods introduced before as extensions to Metaweblog such as wp.getOptions, wp.getMediaItem, etc and introduces new ones such as wp.getPostTypes and wp.getTaxonomies to name just a few.

It’s important to note that only WordPress products are likely to ship with support for this new API at first, but old capabilities will still exist and function, as backwards compatibility is ensured. As API clients add support for WordPress’ new capabilities, we will see more common usage.

Internationalization (i18n) Improvements

For international WordPress users, WordPress 3.4 continues the tradition of enhancing your experience. As we in the community have stated many times, i18n is incredibly important to WordPress growth and development. In discussing this article with someone inside of the WordPress core community, I am told 2 out of every 3 WordPress users are non-American. Additionally, I am told that 40% of WordPress installations are non-english.

That’s Huge!

The running list of i18n chages in WordPress 3.4 is here. Some notable changes include:

• Comma translation. While most languages use a comma as a separater (or delimiter), some do not. This enhancement is useful for languages like Chinese and Arabic that don’t use a comma.
• Single-Double quote translation. It’s odd to think, but some languages like Hebrew, actually have distinct meanings for jots that are punctuation marks in an English world.
• Default Timezones. It’s possible now to override the timezone WordPress uses in a translation. This, as you can imagine, is important when a language is largely spoken in one region in a single timezone.

Page Template Handling

For theme developers looking to put more organization around their theme file structure, a new change has gone in that has both an obvious, front-facing benefit as well as a background benefit. Now, you can place any page template inside a subdirectory of a theme. So you can now have a /pages/ subdirectory and segregate all of your extraneous one-off or multi-use page templates to that folder (or any folder). WordPress will identify all page templates in the theme root or in a subdirectory of a theme root and make them available for pages to use.

The background benefit of this comes in a new WP_Theme API that is lighter weight, more efficient and handles all the work for you. It’s important to note that most developers will never need to use this API and it is largely considered an “internals” thing.

In relation to the i18n improvements discussed earlier, the headers in these page templates are also now translatable. Simply include a Text Domain: and Domain Path: header in your style.css where the textdomain is the defined textdomain for translations (i.e. twentyeleven) and the Domain Path is the path relative to the stylesheet directory (i.e. the proper place the theme is regardless of if it’s a parent theme or a child theme) where the POT file is (/langs). I don’t want to get too deep into this as Andrew Nacin, the architect of this feature, plans to put out a field guide going into detail. Stay tuned to that.

Custom Header API

For a few versions now, WordPress has supported two functions add_custom_header_image() and add_custom_background(). These two functions have added new menus for designating header and background images to the Appearances menu.

WordPress 3.4 introduces a new API for dealing with custom headers and backgrounds and introduces new flexibility in terms of image sizes, etc. The two functions above have been deprecated (which means they’ll work for awhile but will ultimately go away, so use the new techniques) and replaced with new theme support. If you recall from previous version, we use the add_theme_support() function to, well, add support for a feature in a theme. To integrate the new stuff, include these lines in your theme functions.php:

Both function calls can take a second argument which must be an array of presets, but it’s entirely optional. To omit the second argument renders behavior as we’ve known it for some time. To include it allows theme developers to designate designate parameters for both elements, that can then be customized by the end user.

For custom headers, you may include defaults along these lines (gregariously stolen from the Codex):

Likewise, for custom background defaults you might have this:

Bonus

Did you know?

• PHP end of file closing PHP tags are now removed. Those are these – ?> Why is this important? Including the closing tag means that if there is any white space at the end of a file, PHP is likely to break. Omission means that PHP assumes a close tag at the end of the file and whitespace can’t corrupt. Personally I’ve argued for this in the past. The main opponent must have been in a coma when this was slipped through by other core developers.
• Distraction Free Writing, first introduced in WordPress 3.2 is now supported by all custom post types.
• The theme installer now has infinite scroll which is just kind of pretty aesthetic thing. It also defaults to keyword searches when you’re browsing for a new theme on the WordPress Theme repository.
• Internal functions and classes now output “rtl”, “ie7″, “ie8″, etc as classes for browser targetting.

This tutorial will show you how to replicate the functionality that is presented in the “Like” button at Facebook. It assumes that you have WordPress set to require users to be logged in to take such actions. It wouldn’t make much sense for someone to not be logged in for such functionality. Obviously, you could do something else with Ajax (polls? Loading new content?) that doesn’t have the same assumption, but in this case… we’re assuming a user is logged in and the $current_user global is set.

Getting Started

Let’s start with the basic PHP class (you do write good object-oriented code, right?)

This code is just a basic skeleton that provides a constructor (the __construct() method, which I’ll use later. It also instantiates a new My_Like_Button object and assigns it to the $my_like_button variable for use in the global scope. Obviously, you can use whatever strikes your fancy for the class name or the global variable.

Building the HTML for the Like Button

Next, we need the basic HTML structure that will be used in our theme for the Like button. For the sake of simplicity, I’m not providing any CSS, but feel free to do as you wish. We need to add this as a new method in our class.

This form provides two hidden form fields using get_the_ID() and the $current_user object. Having done this (and after ensuring there is a logged in user), we can now drop this into our theme in the Loop as a template tag:

Sending the Ajax Request with jQuery

This is useless by itself. We need something to handle the Ajax. But before we get there, we need to understand how Ajax works within the WordPress context.

All requests must go to wp-admin/admin-ajax.php. Forget the confusion about why you would send a front-end Ajax request to the back-end. You just do.

On the back-end, you’ll have to define functions that will hook into the Ajax API to let WordPress know how to handle the request. More on that in a minute. Let’s build some jQuery to send this to admin-ajax.php.

This is just a PHP function that we can use to throw some jQuery (using the .post() method for our Ajax call) into the head. Note the nonce. You must include this for security. Additionally, you must have an action set. The action is used by WordPress to route the Ajax request.

Finally, we’re passing two extra pieces of data – user_id which is the WordPress user ID and the post_id which is the WordPress post ID of the current $post object inside the Loop. Both of these are supplied in the hidden form fields we created earlier.

Let’s add a new method for hooks and call it in our constructor, so that hooks are executed when the object is instantiated:

Supplying the Ajax Handler

Having hooked the jQuery into WordPress, we now need something on the other end to handle the request and return something back to our page. For this, let’s create a method called handle_like().

In this method, it’s important that all data be sanitized to avoid security problems. I’m performing the most basic of data security here by casting the $_POST variables for the users ID and the post ID to integers.

We’re also checking to make sure the user is logged in. This is why using the built in WordPress Ajax API is actually kind of important. If you build your own Ajax handler, there’s no way to reliable tie in to WordPress to use other APIs like the User API.

Finally, make sure you verify the nonce so you know the request is coming from a legitimate source.

The three security procedures I just listed will largely prevent SQL Injection, ensure authenticated users and eliminate the possibility of Cross Site Request Forgery (CSRF) and generally should be used in all WordPress plugin development.

Simply though, the above method takes the post ID, the user ID and creates a new record in the postmeta table. On success, it will print a success method readable by the original sending page and vica versa on failure.

Note: You must use die() or exit() at the end of the method to make sure the Ajax response exits properly.

Tying the Handler into WordPress

Now that we have a handler method to do our bidding, we need to make sure WordPress knows about it so it routes Ajax requests to the proper place. To do this, we leverage the wp_ajax_{$action} hook.

Remember earlier, while building the jQuery Ajax request, I mentioned that an action POST variable had to be set? WordPress looks to this variable to create a dynamic hook that we can use our new Ajax callback to hook into.

Because our action in the js() method was set to register_like, the hook WordPress creates dynamically is wp_ajax_register_like and we can use that to hook our Ajax handler onto.

Wrapping it all Together

Easy right? Use jQuery to send data, wp-admin/admin-ajax.php to receive the Ajax request and pass it on to an appropriate handler function, and send data back to the original page. On the receiving end, you can use normal means to handle the returned data as you wish.

You can download the full code used here at Github.

So basically, I haven’t had a lot of time to myself. So I took time. In the past few months, I’ve taken some large consulting contracts, but mostly, I’ve spent time travelling to Maryland, Seattle, Chicago – all for pleasure, nothing for work. I’ve spent time trying to weigh my priorities and wants. I’ve tossed around starting up a new company or doing something different.

At the end of the day, now that it’s 2012, I know what I want to do. It’s a bit unusual, but I think it’s important and can really revolutionize a boutique agency. I’m not comfortable doing social media work. I’m too honest and raw in my own online presence and many companies and clients may not be comfortable with my level of authenticity.

I also don’t want to do what is common among agencies – sweatshop site development. Hey, no offense. That’s what it is. Take on 30 new clients, promise them websites that are the brainchilds of the agency marketing “expertise” and ask the developers to crank them out with little to no strategic or creative input.

That might work for some developers, but I’m not a normal developer. I’m a highly established WordPress professional that has commanded 5 figure consulting deals, written a 700+ page book on the subject and have built some of the most complex WordPress solutions I’ve ever seen (Humble brag! Also proprietary, but can provide in person demos). I’m not a good fit for sweatshop site generation.

You know what agencies need that no one is doing because no one has taken the time to think outside the box? A skunkworks division. What agencies need to differentiate themselves from the thousands of other agencies they are competing with is a person or small group of people with autonomy and who are focused soley on creating disruptive technologies that no one else is doing. Try things. Fail at some, succeed at others. Test market demand. Offer exclusive access to stuff that no other agency has. Innovate, innovate, innovate.

That’s what I want to do. And someone sees the sense in that. And someone realizes that that is worth thinking outside the box for. Someone is willing to invest in that competitive advantage. Someone gets it. It’ll take money. It’ll take risk. It’ll take balls of steel. Or you can be normal. Who wants to be normal?

So as we enter 2012, I am open to conversations around this or other creative outlets you might want to explore if you want a competitive advantage. Email me at aaron@technosailor.com.

Last night I was at the Austin Web Holiday party, a gathering of some 15+ technical meetup groups cross-pollinating over beer and socializing. I was introduced to one guy (can’t remember his name!) who had built a video site and enabled it for oEmbed. He couldn’t understand why WordPress wouldn’t just automatically let users use his videos, like it does for YouTube, Vimeo, etc. The full list of default oEmbed providers are listed here.

WordPress doesn’t allow automatic use of oEmbed for security reasons. Otherwise, someone could build a video service stuffed with malicious code that could potentially access your database or create a man in the middle attack or worse. WordPress.com certainly doesn’t allow arbitrary oEmbed sites and the dot-org open source software doesn’t allow arbitrary stuff automatically. But it can be done, on the dot-org side, with a plugin. All it is a hook.

Here’s an example. If you want to register an oEmbed video site that is, say, at (randomly) http:/mysuperawesomevideosite.com and your videos are of the format http://mysuperawesomevideosite.com/video/*, it’s as simple as adding a function in your plugin (or more properly from a PHP perspective, a method in a class – but that’s a personal preference. The method/function should call the  wp_oembed_add_provider() function.

In it’s simplest form, all you have to do is:

Then, to make this code work, just instantiate the class somewhere.

Voila!

With that said, WordPress 3.3 is just around the corner and, as usual, it’s chock full of goodies for everyone. I’d say that the notable changes for developers are the most significant. Improved metadata handling, improved SQL tools, improved cache API and deprecation of several venerable functions are all changes that developers should be aware of.

This article touches mostly on the user experience and features that are new in WordPress 3.3. Developers who want to dive in should reference this running list of “things” that were addressed in WP 3.3.

Admin Bar Overhaul

The Admin Bar that was introduced a few versions ago has become a main-stay of my WordPress experience. At first, I felt like it got in the way, but I soon got used to it. In WordPress 3.3, the Admin Bar gets tweaked and enhanced. For Multisite users, you now have access to the Network Admin from a new “My Sites” menu along with all sites that you have access to ¹.

As usual, developers can modify the admin bar using the admin_bar_menu action, and hooking a callback that modifies the $wp_admin_bar global. This object is created by the WP_Admin_Bar class that provides an add_menu() and remove_menu() method for manipulation.

Sample Code:

HTML5 Admin/Responsive Layout

More Admin-side improvements, like a conversion to HTML5 are a little more understated and less pronounced – unless you’re trying to access it from your iPhone or mobile phone. The conversion to HTML5, while meeting the trends of the day, also have the practical effect of providing an adaptive design which conforms to the device or viewport you are using. There’s nothing too crazy here, but with the web world going in the direction of HTML5, this move lays groundwork for new HTML5 features in the future.

Drag and Drop Media Uploader

One of the biggest new features in WordPress 3.3 (and a long time in coming!) is a new and improved media uploader. This is a feature that is discussed every single release cycle but because there’s only so much room in a major release cycle for major features (and this is a huge rewrite), it has continued to get bumped to a future release – until now.

While the new uploader is not the holy grail and I feel like there’s still a lot of room for improvement, it takes a giant leap forward in making the web interface feel more natural and more like a native application.

What am I talking about? Well, three words: Drag and Drop. With the new media uploaded, it’s as simple as dragging files to the “drop zone” in the native way that your OS allows: On Mac, from the Finder or by dragging the title bar icon in the app you’re using (Photoshop? Preview? Skitch?) into drop zone. On Windows, by pulling your file from Explorer into the Drop Zone.

Plus, related to the last feature, this media uploader prefers HTML5. For the geeky, the failover for HTML5 uploading is first Silverlight, then Flash then the old fashioned “Choose File” HTML dialog.

HTML5 Media Uploader

Welcome Screen and Pointers

If you already are using WordPress, you won’t see the welcome screen unless you setup a new WordPress install ². The Welcome panel gives an overview of WordPress to new users.

More importantly, there is a new jQuery plugin that adds “Pointers” to WordPress whenever a new core, user facing feature is added. In WordPress 3.3, you’ll see one immediately pertaining to the new Admin Bar. However, Plugin and Theme developers who want to highlight new features can also do so. If you know jQuery, the following code is a good head start in the right direction:

Sample Code:

I imagine this will get easier to implement in the future.

Improvements to Distraction Free Writing

Distraction Free Writing, which made its debut in WordPress 3.2, offered bloggers vast improvements to how they wrote content by removing the silly things that, well, distract from the job of writing.

In WordPress 3.3, DFW now integrates the content width and other CSS stylings of post content into the editor. This is all based on the active theme CSS and it attempts to aid the blogger in formatting properly for the theme the content will be displayed in.

Admin Menu Flyouts

A minor enhancement, yet important from a UI perspective – especially for those of you who, like me, constantly have wp-admin menus expanded – are menu flyouts. Very simple little thing, but when a user mouses over a menu, the submenu items under it appear in a “flyout” to the right and disappear when the mouse is no longer over the top level menu. Of course, for touch devices and clicky people, the collapse/expand functionality still exists.

Tumblr Importer

Technically, importers are no longer bundled with WordPress core. They are plugins. However, the removed importers are still listed on the Tools > Import console and can be installed from within WordPress.

An importer that has been in demand for some time, due to the popularity of Tumblr but the more popular nature of WordPress, is a Tumblr importer. Now that is available – also as a one-click plugin – to assist Tumblrs in moving to WordPress.

Tumblr Importer

Go forth and enjoy a better blogging experience. And hey, use Press This if you like the Tumble style.

Multisite – Internationalized Domain Name Support

For non-english Multisite installs, it is now possible to designate an international domain name ³ as the site install domain. In Multisite, this means that base installs of WordPress can use IDNs now, which will serve to increase the adoption of these domains in non-English speaking parts of the world.

ワードプレスのイェーイ.jp, FTW!

Multisite – Network Enabled Themes and Theme Updates

Since we’re on the topic of Multisite, WordPress 3.3 brings the Network Activate option that has been available for plugins to themes. The plugin flow and the theme flow is different in WordPress, so this option makes things significantly easier. The plugin workflow only allows Super Admins to install WordPress and gives the Super Admin the ability to turn off the plugin menu for Blog Admins, but if left turned on, any Admin can activate any available plugin for their particular blog. For plugins, Super Admins can designate a plugin as a global plugin by Network activating in the Network Admin.

For Themes, it was an arduous task of making themes available to sub-sites in the past. Now, after installing a theme from the Network Admin, all it takes is a single click on Network Activate to make that theme available to sites in the network.

Deprecating Feeds

Finally, for those of you who rely on your feeds and are stuck in the stone age still, WordPress no longer supports old RSS 0.92 feeds and RDF feeds. For what it’s worth though, the default RSS feed is the still supported RSS 2.0 feed (add /feed to the end of just about any URL in WordPress and that is your RSS 2.0 feed.

Still, I know some of you don’t like to change and may be using the old feeds. There are two things to note:

1. These now-deprecated feeds will redirect to the proper feed, with 301,
2. If you use FeedBurner, or similar feed repurposing and syndication service, please make sure you are using the RSS 2.0 feed, not the RSS 0.92 feed. Like I said, a 301 will occur but that is actually additional load on the web server because it generates additional HTTP requests

Wrap Up

Sadly, this was the first WordPress release in some time where I have not contributed any code. There are a lot of reasons for that, none of which are all that important. But the core development team has really done a great job with this release and they should be commended.

If you really like WordPress, thank the team with a donation to the WordPress Foundation. All of the work that has gone into this release has come on the backs of volunteers or dedicated, full time paid employees of other companies who have been “donated” to the project.

The tools are Compass combined with Sass (which means Sytactically Awesome Stylesheets or some random crap like that).

Sass is cool because it lets you do a whole bunch of stuff with CSS that you couldn’t normally. It’s a kind of abstraction layer above CSS which means you can write normal CSS if you want, but then why wouldn’t you just write normal CSS instead of using Sass?

I’m getting slightly ahead of myself, but With Sass you can do awesome things like variable/placeholders which is awesome for things like defining core elements of a stylesheet such as a palette of colors.

Then using those variables, you can just use these placeholders in your SCSS (Sassy CSS) file:

You can also write Mixins. Mixins are essentially reusable blocks of CSS that look a lot like functions you would see in languages like JavaScript, PHP or Ruby:

You can use that in your SCSS file as such:

But again, I’m getting ahead of myself.

When I talked about using Sass and Compass on Twitter, other WordPress devs made comments that made me want to write this tutorial. One person said that they were tired of Rails developers having all the toys – and it’s true. There are so many awesome things out there for Rails developers that we as PHP and WordPress developers don’t benefit from. This tutorial is non-exhaustive. There are tons of things that you can do with this that I won’t cover. But this should get you going with Mac OS X Lion, developing WordPress locally on your own machine and uploading to a theme file called “test” on a remote server.

Prerequisites

First of all, you need to have a local version of WordPress running. There are a variety of ways to do this, but I use the approach of installing XAMPP. Here’s a tutorial on that. Follow the rabbit trail to configure Apache to look to your Sites directory, as I have, or make that translation in your head to what the default is. There’s plenty of instruction on how to do that on the internet.

For the specifics of this tutorial, it’s very important that you have the latest version of Ruby. The best way to do this is with a tool called rvm, or Ruby Version Manager. Install this with the following Terminal command:

Once rvm is installed, use it to install 1.9.3-p0, the only current version compatible with OS X Lion, and refresh your Terminal profile settings. The last command sets 1.9.3-p0 (or whatever future version you choose to use) as your default.

If you wish to verify that you’ve got the proper version of Ruby active, verify it with the ruby -v command.

My system reported:

Now, there are some gems that need to be installed. For developers unfamiliar with Ruby – or Rails – gems, are essentially additional libraries that are installed into the Ruby framework, much like PHP PEAR or PECL modules.

The first is Builder, which is used for building XML structures. The second one is Compass which will give us the ability to leverage Sass for CSS authoring.

Creating a Sass Project

Once we have everything installed properly, we can start a new project. I keep this out of my web directory (i.e. WordPress structure). Personally, I’ve created a sass directory under my user profile (/Users/aaron/sass) and run my projects out of it with a separate directory for each project.

Now we have to create our compass project. We do that with compass create from our ~/sass directory and then moving into the newly created directory.

Doing a directory listing should show something along these lines:

Good. Our project is created but we need to make some changes to make this work with WordPress. To do this, we need to edit the config.rb file which is the project configuration file. You can edit this file in Textmate, vi, or whatever you choose as your preferred text editor.

The default configuration is:

My config file looks like this:

Important changes here:

• The http_path is a relative path to my DOCROOT – for some reason, things got whacked when using an absolute path.
• The css_dir is a relative path to the css directory in my WordPress theme directory. At this time, there is no configuration option to control the name of the CSS files being generated so we will have to use @import inside the required WordPress style.css template file to incorporate Compass generated CSS files.
• You can change the images_dir and javascripts_dir as needed to reflect your taste. Personally, I prefer shorter names, so that is reflected in the config file.
• The project_type flag is required because, if omitted, Compass assumes we are working in a Rails environment on a Rails project with Rails conventions… WordPress is none of that.
• The output_style flag has been set to :nested but could be :expanded, :compact or :compressed depending on your tastes.
• The line_comments flag has been set to false to remove debug information from the generated CSS

All configuration options can be referenced in the Compass docs.

Having modified the config file, we can take one of two approaches to generating the CSS in our WordPress theme. We can use the compass compile which will generate the files one time. Everytime modifications are made, however, this command would have to be re-run. I prefer, instead, to use compass watch which is a small process that remains running and watches your Sass project for changes and recompiles automatically when changes are made.

Simply run this command from inside the Sass project:

At this point, if you want to develop locally, all you have to do is have your WordPress style.css import these stylesheets.

Uploading to a Remote WordPress Install

Fortunately, with a little Ruby magic and some built in Compass hooks, we can also upload these newly created CSS files to our WordPress theme. In order to do this, you have to make sure the remote server has the theme directory created and if you are uploading to a subdirectory of that theme (e.g. theme_dir/css), that that directory is created as well.

In our case, the theme directory is test/ and I want to upload to a subdirectory test/css/.

Next we have to install two new gems – the Net::SSH and Net::SFTP gems. Installing these is as straightforward as the earlier gems:

Once this has done, include these in your config.rb file. I did this at the top which is best practice with Ruby.

Below all the previous configurations, add some configuration lines and replace values as needed for your own project:

Finally, we can leverage Compass’ built-in on_stylesheet_saved hook to upload to the remote server using your SFTP credentials:

Restart Compass, save one of your Sass .scss files with a change of some sort (from where CSS will be compiled), and watch your files be saved locally and remotely.

At this point, my full config.rb file looks like this:

Conclusion

Rails developers have all the fun. It’s true. But with Compass, Sass and a little bit of Ruby, PHP developers (including WordPress theme developers) have a great tool that will make workflows more efficient, CSS more readable and structured and central management more coherent.

Obviously, I did not get too far into the details of using Compass and Sass. That’s a whole tutorial to itself. For information on that, I’d recommend checking out these fine articles written on the topic:

• Using Compass and Sass for CSS in Your Next Project (NetTuts+)
• Official Sass Tutorials (sass-lang.org)

(Protip: I love being able to nest CSS… try it)

Disclaimer: I am a PHP developer, not a Ruby developer. My Ruby code could probably be improved upon by someone who is more in tune with the Ruby language.

Effective immediately, I will be taking the portion of the business that focused on professional services and consulting to allow the company to focus on premiere WordPress hosting. It’s a good thing and I’m excited about the possibilities. Back in November, we decided to start taking on some professional services work to augment demands from many of our customers. It was awesome to have fast, secure, scaleable, managed hosting but they wanted more!

And we wanted more.

However, as the company has evolved, taken funding, hired more people, addressed growth challenges and built out our hosting option, it seemed clear that the professional services portion of the company was a separate kind of deal than what we wanted to focus on.

So today, I’ll be taking that portion of the company (and all related existing and current relationships, as agreed on), and working on that. Meanwhile, I’ll still be working with the company to guide direction and strategy. So it’s good for everyone.

Effective immediately, I am available for all WordPress consulting roles. However, I am also currently entertaining all possibilities involving full time employment as well, and welcome those conversations.

To contact me, please direct emails to aaron@technosailor.com. As transitions go, the immediate financial impact is something that I need to consider.

The repository can be found at http://core.svn.wordpress.org/ and a primer on how to use SVN for WordPress development can be found on Mark’s blog and, for Windows, on Westi’s blog.

Though there are varying schools of thought as to how branches and tags work, WordPress follows the following system:

/trunk is where future release development occurs. Right now, WordPress development is focused on an upcoming 3.3 release. All development for this release is going into /trunk.

/branches is where 3.3 will go once it is released (or where future “branches” of the software will be housed down the road. The directory contains a series of directories that are branches from the current release development — for example, /branches/3.0, /branches/3.1, /branches/3.2, etc. What you won’t find in branches are security (or dot) releases.

For instance, when a security vulnerability is discovered, it will be patched in /trunk for the current development branch and may be backported to the previous release branch (currently, 3.2). But until the next security release of WordPress comes out for that branch, it is still considered “development” and not “stable”.

/tags is where stable releases are archived. No development goes into tagged releases. These are final releases. You will find every release here in the form of /tags/3.2.1, /tags/3.2, /tags/3.1.4, etc. If you’re looking for the latest current stable for production, this is the place to look.

When branches achieve the next milestone (i.e. a maintenance or security or “dot” release), this is the place where the code is kept.

Hopefully this makes the WordPress repository (and maybe other projects) clear as mud.

Out of morbid curiosity, I decided to run all of those posts through a word cloud generator and see if there were any trends that could be seen. Of course, it’s my writing so there are obvious tendencies and biases, but it was fun to see anyway.

One thing I did to make the results better… I removed the words WordPress and WP. Also, several of the posts had my name in it so I figured it would be better not to include that either.

WordPress 2.0

WordPress 2.1

WordPress 2.2

WordPress 2.3

WordPress 2.5

WordPress 2.6WordPress 2.7

WordPress 2.8

WordPress 2.9WordPress 3.0WordPress 3.1WordPress 3.2

WordPress 3.2 will be released soon (at the time of this writing, it is in RC1 which essentially means it is done and being tested). This is an exciting release as it marks the first release that drops PHP 4 dependency. For years, WordPress has opted to play to the lowest common denominator while hosts have taken their sweet time arriving at PHP 5.

Of course, this may mean nothing to you, depending on your technical knowledge of the underlying language. However, it has limited the amount of innovation that could be possible using the more modern version of PHP 5.

The focus for this release was to slim down redundant code that had been added along the way to employ PHP 5 techniques in a PHP 4-compatible fashion. In addition, a focus was placed on slimming down code all along the way to provide a more efficient codebase. Eliminate, eliminate, eliminate! More Red than Green – a reference to the way changes are recorded visually where red is code elimination and green is code addition.

Regardless, the approach to PHP 5 adoption has had a positive effect. Approximately 12% of the web is powered today by WordPress, whether self-hosted “.org” sites or Automattic’s WordPress.com and other hosted WordPress sites.

As I have done eleven other times before, today I bring you the Ten Things that, in my opinion, you should know about WordPress 3.2.

Twenty-Eleven

One of the big things that was discussed internally around the time when WordPress 3.0 was released over a year ago was the need to keep the default theme fresh. To that end, for WordPress 3.0 did away with the old Kubrick theme and replaced it with the fresh and semantic Twenty-Ten theme.

Yes, you can see how naming a theme Twenty-Ten in 2010 setup the opportunity for a Twenty-Eleven theme in 2011. And there is that opportunity for a new theme called Twenty-Twelve in 2012, but let’s not get too far ahead of ourselves.

Twenty-Eleven visually is not a huge departure from Twenty-Ten. It still uses much of the same visual layout that Twenty-Ten did. The new theme, however, is greatly different behind the scenes.

Note: This blog (along with all of my blogs) are running Twenty-Eleven right now.

Users of Twenty-Eleven have the opportunity to select a one-column or two column layout for their blog from inside the WordPress Admin. The two column layouts can use a sidebar left or sidebar right variant.

My photoblog uses a one-column format, as an example.

Additionally, Twenty-Eleven also offers a dark and light color scheme. My photoblog, for instance, uses the dark format while this blog uses the light format.

Finally, as with Twenty-Ten, the theme allows for custom header images (or no header images) and backgrounds. Because of the professional nature of this blog, I’ve opted to use no header on this blog and my personal blog utilizes a custom header image.

And of course, as with all things WordPress, no one says you have to settle for what Twenty-Eleven offers out of the box. In fact, it is encouraged that you use Twenty-Eleven as a parent theme that offers all of the benefits of the default theme while putting your own spin on it with a child theme.

Distraction Free Writing

While I write this post, I am using the successor to the Full-screen mode that has been in WordPress for some time. Full screen mode, in my opinion, never really was well adopted but it has been championed in the past by bloggers who focus on efficient workstyles, or Getting Things Done (“GTD”) approach to work.

The ability to shut out all distractions so as to focus on the task at hand is hugely important. WordPress core developer Mark Jaquith has said for years that his vision for WordPress was that it would become a tool that got out of the way of people and their writing. It’s not about WordPress. It’s about writing and the experience should be such that you should never have to think about what tool you are using to do that.

With Distraction Free Writing, you have just that. By clicking on the Full Screen (in HTML writing mode) or the new icon for DFW in the toolbar of the visual text editor, the blogger finds themself on a plain off-white canvas with minor tools along the top of the screen to assist in basic formatting. If you leave your hands off the mouse, even these fade away allowing you to just write in a pleasant, serene environment.

This feature is probably my favorite in WordPress 3.2 and usability/writer-facing features are rarely my favorite as a developer. I generally prefer new APIs and developer tools. However, this feature wins hands-down.

Minor Overhaul to Administrative UI

It’s been several years since WordPress has undergone a major Admin overhaul. There have been tweaks along the way, but by and large the administrative interface has stayed true to what it evolved into (with much research and usability testing) in WordPress 2.7.

There is not a drastic overhaul in WordPress 3.2, but it is the larger than a few tweaks and color scheme modifications. In WordPress 3.1, the Admin Bar (which I’ll talk about later) came into being and in 3.2, emphasis has been put on placing more commonly accessed functions into it as opposed to the main UI.

As a result, familiar things (which were often used for blogs in Multisite mode) such as the “Favorites Menu” have been removed to the Admin Bar. The Quick Access menu that allowed Multisite Super Admins quick access to the “Network Admin” has been relocated to a less-than-obvious dropdown  in the upper right. Hint: The dropdown menu can be accessed by clicking the “Howdy Aaron” link, where “Aaron” is your username.

Other aspects of the new interface are mainly aesthetic. Menus are where you’d expect them. Features are where they’ve always been. Plugin developers who have built UI for their plugins are still safe as long as, as usual, they are using the WordPress best-practices, i.e. using the same HTML formats and structures used in core.

More Determined Move to the Admin Bar

As mentioned before, the Admin Bar has become the focus of a “Command Center” approach. By default, quick actions like Adding a new post or editing a page or getting quick access to the dashboard of other Multisite sites are loaded into quick menus in the Admin Bar.

This is also where the philosophy of plugin development that provides quick access to features should be. A good example of this is the Purge Cache functionality in W3 Total Cache. Where this has been in the Favorites menu inside WordPress, it now will have to move to the Admin Bar. This seems like a more natural place to me anyway. Other plugin developers should look at their code to ensure that they are compliant with this approach.

John Brook has a most excellent tutorial on creating and adding menus to the Admin Bar.

PHP 5.2.4 and MySQL 5.0

I mentioned the new system requirements at the beginning of this article. This shift to PHP 5 has been a long time in coming and was done deliberately to time with WordPress hosting on PHP 4 dipping below 10%. In other words, it is more than likely your host is already on PHP 5.2.4+. However, you should verify this if you’re not sure.

With the adoption of PHP 5.2.4, there is also a bump in the requirements for MySQL. Now WordPress requires MySQL 5.0, another hurdle that is not very hard to overcome but should be verified if you’re not sure.

Ryan Duff has created a quick and easy plugin that can be installed to ensure compatibility with WordPress 3.2.

For Newbies, a Better Help Menu on Each Page

For some time, WordPress has included a contextual “Help” menu in the upper right of many of the screens in the admin interface. However, with WordPress 3.2, every page has a help menu. Not only does every page have a help menu, newbies can get detailed contextual assistance for each page. Veteran users already know their way around, so this will be less than helpful, but for n00bs, the guidance lowers the barrier to entry.

Upgrade Enhancement – Just the code you need!

Think iOS5 but for WordPress. When Steve Jobs announced at WWDC recently that iOS updates would in the future come in smaller packages applying just new code and differences over the air, WordPress was already working on this (errr, except the over the air part).

Up until WordPress 3.2, upgrades were performed by downloading the entire package and applying it over the existing install. While this was fine, it took a lot more time due to the larger package size. This new version will enable future upgrades of WordPress to be done incrementally making the process much faster and efficient.

Code Efficiency enhancements

A huge emphasis was placed on core efficiency in this release. Many of the updates that have gone into this release have been major refactoring of code as well as the removal of legacy (and now unneeded) PHP4 compatibility code.

When I write these articles, I like to look at a diff file of all code changes between the last major release and the current. I was blown away by the amount of PHP4 compatibility code that has been axed.

Additionally, a lot of effort has been placed on database optimization. Many queries have been made more efficient. These things are less notable for smaller sites, but for large sites and hosting companies (such as my company, WP Engine), these types of optimizations add up in orders of magnitude!

File System API

Another optimization that has been made (getting the clue that this release is all about streamlines?) has been in the code that handles upgrades and automatic installs of plugins. When the original code was written, it was written to find what methods were available to write to the filesystem. This was because WordPress does the best it can to be as compatible as possible with as many server configurations as possible.

Some of the more obsolete (and unnecessary) transports have been done away with in favor of Streams. Though streams existed in PHP 4.3 (WordPress’ former system requirement), the upgraded requirement now allows us to do so much more with file transfer, handling and writing.

But I don’t want to get overly technical right now.

No IE6 Support

We all knew Internet Explorer was dead. Well, most of us. Believe it or not, there are still folks (mostly in government and enterprise organizations) where IE6 is still in use. While WordPress has always endeavored to be as compatible with as many configurations as possible, just like file handling replaced by Streams and PHP4 going the way of the Dodo Bird, IE6 can die in a fucking fire too. Oops. Sorry, kids. No more IE6 support.

Automatically approve parent comments

Finally, a longtime nuance has been comment approval. Comments have always been a one-to-one relationship with approval. You approve one comment at a time. And while that’s normally fine, what if you have nested comments and you approve a child comment but not a parent comment? Then you have a weird hierarchy that may not make a lot of sense.

In WordPress 3.2, now when you approve a comment that has an unapproved parent comment, the parent comment will also be approved. Many people have asked for that and now it’s here.

BONUS: Credits Screen

But wait… There’s one more thing. Every release, hundreds of people participate in the development process by writing code, contributing patches, discussing ideas in IRC and on Trac. That doesn’t even begin to acknowledge the testers, translators, and documentation writers who contribute their time free of charge.

Now, in the footer of the WordPress Admin, you’ll find a Credits link that shows everyone who has contributed to this release. Good job, guys! (I’m one of the contributors).

This edition of my book has 60 new pages in it and covers up to WordPress 3.1. So all that stuff about post formats, custom post types, custom taxonomies, the merge of WordPress MU into WordPress as Multisite, the terminology changes… all of it…. covered in this book.

I didn’t get everything right in the first edition. There were glaring omissions, politically incorrect moves (such as coverage of non-GPL products), and blatant mistakes. These have all been corrected in the second edition.

I’d love it if you supported the book and me. Please leave a review on Amazon as that helps drive more sales as well as proves the market for the book.

But here’s the question… how can the WordPress Bible, and the whole Bible series, be better? If you own more than one, what do you feel the strengths and weaknesses of the books are. Where can I (and Wiley) improve. This feedback is super-important. Feel free to email me on that if you don’t wish to publish publicly in comments.

Finally… if you take a picture of you with your first edition book, post it to Twitter to my attention, you have the chance to win a free signed copy of the second edition. I have my criteria for selecting a winner, but that will remain unshared for the time. So get to snapping and tweeting. :)

Version 3.0.4 of WordPress…is a very important update to apply to your sites as soon as possible because it fixes a core security bug in our HTML sanitation library, called KSES. I would rate this release as “critical.”

Simple enough. He goes on to refer to the vulnerability as an XSS vulnerability which caused a bit of angst on Twitter about what that means and if non-technical users should be given more information due to the terminology.

So, as a public service, I give you some basic definitions and concepts of web security and what we mean. These concepts are rightly scary, but the names tend to be scarier to those who don’t understand them.

XSS

XSS means cross site scripting. Cross site scripting attacks are generally attacks that occur because something is injected into a URL or “event” on a site to make the site do something else. Do something else can mean “hijack” a site so all visitors are sent somewhere else, or special HTML is injected into a site (often in the form of hidden links that diminish Google search results for the site, etc). This was the nature of the vulnerability fixed in WordPress yesterday.

XSS attacks are almost always carried out because of JavaScript injection. WordPress does have security API that makes dangerous characters (that is, special characters that make JavaScript do things) and it is encouraged that all plugin and theme developers use these APIs. [Docs]

CSRF

CSRF means Cross Site Request Forgery. With CSRF attacks, browsers (and sometimes other things) are hijacked to “do” things to a website without a user knowing. It’s the proverbial trojan horse where there is an inherent trust from a site that the user/browser is doing something trusted and so attacks riding the coat tails of such trust are given the same trust that the user would also get.

A simple example (does not actually exist) would be that an authenticated user in WordPress with admin privileges is tricked into clicking a link (as the authenticated user) and then admin privileges are transferred to the attacker. We’ve seen this kind of attack on Facebook and Twitter before where DMs or messages are spread across Facebook walls or via Twitter DM).

SQL Injection

SQL Injection is an attack that, without going into the technical details, allows an attacker to send special queries to the database that can alter, modify or even delete a database altogether. You don’t see many of these anymore because most apps are built on frameworks or platforms (like WordPress or Drupal) that have built in routines and APIs that prevent this. In WordPress, there is a prepare() function in the database class which ensures that no SQL injection is possible.

0Day Vulnerabilities

0Day (that is Zero, not “Oh”) is a vulnerability that is exploited before it has been disclosed. Many security researchers work closely with web application developers to alert them to newly discovered vulnerabilities before they are publicly disclosed. They then work with the developers to close the hole before disclosing the vulnerability. The term 0Day comes from the idea that the web app developer knows about the exploit on the 0th day after public disclosure (it hasn’t been disclosed yet).

Denial of Service/(D)DoS

(D)DoS is a (Distributed) Denial of Service attack. These attacks are carried out by flooding a site with traffic/requests to the point where the site can no longer handle the traffic and collapses. If the attack comes from a single source, it’s a DoS but if it comes from more than one, it is a DDoS.

Obviously, there are many aspects of security. We could go way complicated on terminology and concepts, but these are some of the basics you should know when you see something about a vulnerability.

Photo Credit: heathbrandon

I made a point of making my event one that would set trends and challenge the status quo.

Mid-Atlantic

One thing I did think of early on was that I detested the trend that identified an event with a singular city, especially when there were multiple cities, all offering different, yet complementary modus operandi. I bucked the trend of identifying the event by a city, eschewing names like WordCamp DC or WordCamp Baltimore. These names, while celebratory of the city that hosts them, inherently bear the problem of inferred exclusivity.

From the very first WordCamp in the region, I challenged that designation and attempted to bring the cities together. It was called WordCamp Mid-Atlantic.

Three Cities, then Two

The original plan was to bring the three cities together in Baltimore for a WordPress event. Ideally, the result would be more collaboration and resources shared between the various communities. Ultimately, Philadelphia never bought into Mid-Atlantic (and in fact, ended up with their own successful WordCamp Philly). However, Mid-Atlantic was wildly supported by both Baltimore and DC. even garnering coverage in the Baltimore Sun business publication Maryland Daily Record.

For WordCamp Mid-Atlantic 2010, the event was geared mainly to the Washington Metro and Baltimore.

Keynotes That Challenge

In both events, I wanted to bring in someone from the WordPress leadership hierarchy as a Keynote as well as someone from outside of WordPress entirely to challenge the gathered attendees. This as quite controversial, actually. In 2009, I brought in Anil Dash, founder and former SVP at SixApart. Anil was known historically as somewhat of an antagonist, but did a wonderful job in sharing and illustrating the similarities between WordPress and SixApart who provided a competing platform. His message was one of learning from each other.

This past year, I opted to bring in Marco Tabini who has also been a frequent antagonist of WordPress. His message was one from the perspective of the PHP community and reconciling how the PHP core people could learn and help the WordPress core people, and vica versa. My inbox became a little tense in the weeks leading up to the event due to other incidents involving dissenting views about the GPL license and WordPress’ interpretation of it. Needless to say, Marco did an amazing job.

It’s Not My Baby

As most of you know, I have left the Baltimore/Washington region. As a result, this past WordCamp Mid-Atlantic was my last. People have asked me quite a lot about who I would pass the baton to. This is a tricky question because the event is not mine. It’s yours.

That said, this is not for just anyone to run. I cannot put any strings on who will run the next event but I do have the platform to voice my sentiments:

• I want to see Mid-Atlantic stay in the event. I do not want to see a fractured event where there becomes a WordCamp Baltimore and a WordCamp DC. Both cities have user groups that meet frequently. I want to see the WordCamp Mid-Atlantic event retain it’s place as a regional/local event.
• I want to see the idea of challenging (and even dissenting) opinions welcomed to the stage, like Marco… and Anil. We should not be scared of being shaken up. We should embrace it and learn from it. That said, future organizers should be sensitive as to who you have come and speak.
• Retain the unconference. One of the amazing success stories of WordCamp Mid-Atlantic 2010 was the unconference, organized by Steve Fisher. Besides the pre-scheduled and organized tracks that are familiar to conference goers, we provided a separate, yet equal unconference for ad-hoc discussion and talks. The only thing I’d change is to make it true barcamp style and make a no-powerpoint rule.
• No one organizer. I became the defacto organizer for both events. While I had varying degrees of help for both, I really became the guy for the event. This was not wise on my part. There should be an organizer in each city.

This is Baltimore’s event. This is Washington’s event. This event brilliantly integrated both communities. It really, really did. I want to see it continue (obviously with new leadership), but I want it to be with people who take it seriously and can make it better than it ever was. Put your own spin on it. Make it your own, not mine.

It was very interesting. Back in May, my friend Pete Jackson, who works for Intridea, started making a point of introducing me over to Twitter to one of his friends in whatever city I happened to be travelling in at that moment.

It was in this way that I met Sean Cook, the manager of mobile integrations at Twitter in San Francisco and, when I was in Austin visiting in May, he made sure that I met Aaron Scruggs of Other Inbox who has since become a pretty good friend.

It was after that meeting with Scruggs in May that he connected me to one of the smartest guys I’ve ever met, Jason Cohen. Jason is one of the two founding partners at Capital Thought, an Austin-based incubator. Jason has also built several companies and parlayed two of those into healthy exits. I’ve come to have a tremendous amount of respect for his technical and business savvy.

Jason described to me the concept for a business that he was working on along with Cullen Wilson. A premium, WordPress platform that would cater specifically to the customers who want to make sure their blog is always taken care of from a maintenance and upgrade perspective, but also would offer significant value adds that nobody else is providing in a WordPress-optimized environment.

I’ll get to what all those buzzwords mean in a minute. Stick with me.

We started talking about me joining up with them to take this idea to the bank. Shortly after moving down here to Austin, I joined the team and we’ve been working hard over the last couple months to get to the point where we could reliably take on new customers and talk about our idea publicly.

Today is that day.

So, you’re still probably wondering what the hell WP Engine is and why it’s important, right?

Let’s talk security for a minute. There have been significant security “incidents” in recent months. Most people on the outside simply see “WordPress hacked! WordPress hacked!” – I’m looking at you Chris Brogan, Robert Scoble and Frank Gruber (Techcocktail). In the WordPress community, we know the real issues in these cases were not WordPress but the hosts that the blogs were on. Still, people saw WordPress hacked.

We take this very seriously and have partnered with a provider that has multiple levels of security including Intrusion Detection Systems (IDS) outside of our boxes. We have gone to great lengths to keep our customers connecting to us in very secure ways and keep a close eye on the activity happening on our boxes. This is all very important because if an attacker could get through our outside defenses, chances are they couldn’t do anything malicious without us knowing about it.

Our infrastructure is also built with optimization and blazing, fast speed as a core expectation and deliverable. We don’t overload servers and have the means to see potential performance problems before they arrive. With our dual nginx-apache server configuration, we are able to handle sustained high-volume traffic as well as spikes that are the pain point for WordPress bloggers who suddenly get a story featured on a prominent site.

For the people who claim WordPress doesn’t scale… I call bullshit. We believe we know exactly how to make WordPress scale.

But we’re not just a hosting company. If we were that, we would be our competitors. We are also working on additional features such as “Curated Plugins” which are plugins that are entirely open source, that are popular or in demand from our customers and have been vetted from a security standpoint. These are plugins that we support 100%. This does not preclude customers from using other non-supported plugins, and we don’t dictate what bloggers can have on their blog as some of the other hosted WordPress solutions do. We just say, “Hey, if you use one of these, we’re gonna have your back”.

WordPress is a free software that is licensed under GPLv2 – a license that was created in 1991 to protect the ability of developers and users to gain access to software, create derivative works and distribute the copyrighted code in its entirety under the same protective license.

One of the tenants of the GPL that is argued prolifically is that derivative works are works that “link” into other works via APIs and dependencies (such as library dependencies). According to the argument, software that is considered a derivative work must retain the same licensing as the GPL’d work that it links into.

There are many legal (and non-legal) minds who would like to interpret this license in a variety of ways. There have been notable legal cases around the GPL in the United States, but all (to the best of my knowledge) have settled prior to litigation. One of these cases, Progress Software v MySQL AB, revolved around a product called Nusphere that was bundled with MySQL but was proprietary and incompatible with the GPL. The judge refused to grant summary judgement and eventually MySQL simply did not bundle the proprietary software.

Another case avoided judicial decision – and thus avoided judicial precedence. That case, Free Software Foundation v. Cisco, was settled out of court with a donation from Cisco and a pledge of commitment to the GPL.

Today, a major incident happened that has been brewing for years now. Due to an unfortunate incident which involved source code for the popular Thesis theme for WordPress (from DIYThemes) becoming compromised by a hacker, tempers started boiling over. Matt Mullenweg, founder of WordPress and the public face of )Automattic, the largest company behind the WordPress project, ended up on a live interview alongside Chris Pearson of DIYThemes.

Matt suggests (I think accurately) that a theme that is provided for WordPress (it does not work without WordPress) is a derivative work and requires GPL compatibility. He also suggests (accurately, I think) that GPL compliance would only enhance DIYTheme’s business as evidenced by countless other proprietary software providers who have gone open source.

Not to mention that a license does insinuate adherence to legal requirements provided by the license. If you don’t agree to the terms of the license, you’re not permitted to use the software. Makes sense.

Chris’ defense is that Thesis is completely independent of WordPress (which I question the rationality of since the software cannot exist absent of WordPress). He believes he has a business and economic right to maintain a license that is at odds with WordPress’ GPL license.

So my editorial question is… compliance with the WordPress GPL license is optional but compliance with the Thesis license is not? Hmmm.

Matt, in so many words, has already indicated that there will be a lawsuit that comes out of this. This could be landmark as, if the suit were not settled, it could define the parameters of open source software creation, usage and distribution reaching into every aspect of our life. Who uses Firefox? Yeah… depending on the outcome, that could be affected.

In a perfect world, the two sides reach an amicable solution. Thesis is popular, but it is not the only game in town. However, the second best solution is a legal precedent governing GPL software.

So we stand by and wait.

Image by Joe Gratz

This is somewhat of an odd release as I can’t point to 10 individual new features in WordPress. However, I can point to several very large new features that have been hyped enough already. Inside each of these new major things, there are several components. So, let me break the ten things down into three groups. We’re a little behind schedule (thanks to Jane Wells’ cat below) but I think the wait is worth it.

The Merge! WordPress and WordPress Multisite Together At Last

Back at WordCamp San Francisco last year (which is happening this weekend and I will be at), Matt Mullenweg announced that WordPress and WordPress MU would be merging into one singular software package. I covered that shortly after the announcement. The reasoning was that all of the WordPress core was already in sync with WordPress MU and MU simply had a bit more functionality added to it. Most of the code is the same. Why split resources and developers?

WordPress 3.0 is where this merge takes place.

Language Changes

While this is not a new feature in WordPress, existing WordPress MU users may find themselves “thrown” by new terminology involved in WordPress 3.0. In WordPress MU, we had the concept of a “Site” which was an installation of WordPress MU. Within a Site you could have one or more blogs.

In WordPress 3.0, we have the concept of a Network (which was a Site in WordPress MU) and under a Network, we have Sites (which were Blogs). Sites are Blogs. Networks are Sites. Site Admins in WordPress MU are now called Super Admin’s in WordPress 3.0. Making things complicated, we don’t call it WordPress MU anymore. We call it putting WordPress into Multisite mode. Complicated, eh? New WordPress Core Developer, Andrew Nacin, describes this terminology nightmare.

Enabling WordPress for Multisite Mode

Something that is bound to be confusing for users who expect to simply install WordPress and get all the benefits of Multisite out of the gate are bound to be confused by the fact that there is no apparent “switch” to turn it on. When you install WordPress 3.0, it will be in standard WordPress mode. In order to flip the switch, you have to add a new constant to your wp-config.php file. It’s easy, just add the following and save:

define('WP_ALLOW_MULTISITE',true);

Once this is done, you’ll find a new menu item called “Network”  in your Admin under Tools. Visit this page, enable Multisite and follow the instructions. You may need to add new configuration settings to your .htaccess file and wp-config.php, but WordPress will provide these lines for you to copy and paste.

Note: As with WordPress MU, you may need to make server level system changes to enable WordPress to handle subdomains. This is not an easily solved problem and caused heartburn with MU users and will likely continue to cause heartburn with WordPress 3.0 users as well.

Upgrading from WordPress or WordPress MU 2.9 or below

A lot of people, including myself, were concerned about upgrade paths when the Merge was announced. I should have known not to be concerned. WordPress has taken great care for years to ensure backwards compatibility and we’ve done the same thing here. If you’re on WordPress or WordPress MU, you will be able to install WordPress 3.0 and upgrade seamlessly. WordPress MU installs will become WordPress 3.0 with Multisite enabled and single installs of WordPress will retain all the benefits of standard installs of WordPress.

WordPress as a CMS: Custom Post Types and Taxonomies

Developers are already very excited about the new APIs available in WordPress 3.0. Specifically, Custom Post Types (which received initial support in WordPress 2.9). This is a very important set of new features because it finally – finally! – brings CMS support to WordPress. For the first time, we don’t have to simply pretend that WordPress is a CMS…. it can have all the CMS qualities of a Drupal or Joomla.

Custom Post Types

We initially talked about custom post types in WordPress 2.9 but in WordPress 3.0, the feature is fully vetted and able to be utilized. With a simple function in a plugin or theme, developers can create new post types (such as film reviews, podcasts or FAQs), provide entirely familiar UI (similar to posts and pages), etc.

You can find all the possible options under register_post_type() in the wp-includes/post.php file.

Custom Taxonomies

Going hand in hand with custom post types, you can also create custom taxonomies. Taxonomies are bits of metadata and most people think of them in terms of ‘categories’ and ‘tags’. Built into WordPress already are three taxonomies – categories, tags and link categories (which most people think about). The difference, from a technical perspective, between tags and categories is hierarchy. Categories have hierarchy so a category can have a child category, etc. Tags are flat and have no hierarchy.

You can create custom taxonomies with the register_taxonomy() function which will create UI automatically. All the options for custom taxonomies can be found in the wp-includes/taxonomy.php file.

Note: I have created a plugin and made it available for download that demonstrates how to use custom taxonomies and post types.

User Facing Enhancements

There are two major user facing enhancements. When I say two major user facing enhancements, I’m not being sensational. These things are killer and I think you’ll be excited.

Menus

Wow, this has been a controversial new feature. Mostly because it almost didn’t make it into WordPress 3.0 and users have really, really wanted it. Those familiar with the navigation creator in many of the WooThemes will be familiar with the new Menus feature in WordPress. This is because we worked early on with Woo to adopt their premium theme feature, which was very good, into the WordPress core (a fantastic case study on how premium theme developers can work directly with the WordPress core team).

The idea is really simple: Compose any menu with any hierarchy out of category archives, pages and custom links. Once a menu is created and saved, theme developers can enable support for this feature with the following line:

enable_theme_support('nav-menus');

Dropdowns are automatically created and semantic CSS markup allows style modifications easily. You can also create multiple menus (let’s say, a secondary navigation piece) and use them as sidebar widgets or hardcode them directly into a theme.

Default theme… no, no default theme… no, new default theme!

Well, you know all those free themes over on the theme repository? Yeah, most of theme are heavily modified versions of Kubrick, the default theme for WordPress. Theme people would take the code base, modify it and make it their own. They might upload it to the theme repository. Problem is, they would not be updated with the new stuff that would go into Kubrick. That and Kubrick sucked as a theme.

Well, as of WordPress 3.0, there is no more Kubrick. There also is no more Classic theme. Now, we have a new theme called twentyten. Yes, that means next year, we’ll have twentyeleven.

Twentyten is a very complex theme. It should not just be duplicated and hacked up. We want themers to adopt the child theme method of doing things. This is important because as changes go into twentyten, your child theme will inherit those changes.  Here’s a good starter for how to build child themes.

Note: If you are upgrading from previous versions of WordPress and have a child theme based on Kubrick, don’t delete the default theme. If you do, you can still grab the theme from the theme repository.

WordPress Admin Enhancements

The WordPress Administrative interface has also seen enhancements. Jane Wells is our usability expert in the WordPress developers group and has done quite a lot of work. Minor enhancements include an all light-grey style color scheme (as opposed to the dark grey header bar). This does seem to be better on the eyes. Additionally, the themes interface also has a new “tabbed” interface.

Custom Backgrounds

Built into twentyten is a new custom background feature. The cool thing is, theme developers can include this feature in their own theme. Simply adding this function to your theme functions.php will add a new menu item to your Appearance menu that allows for quick modification of the background image on the blog.

add_custom_background();

The Extras

Of course, not everything can fit into the three main areas of feature adds. Some are important and just don’t fit anywhere else.

Admin Username

Many of the security problems that have occurred in WordPress’ history have been a result of the administrative username being admin. This has not been selectable or changeable without hacking the database and changing the admin username there.

In WordPress 3.0, the username can now be selected on install. Here’s a hint…. don’t name it admin. :)

For a complete list of expected changes, see this Codex page.

Some of my answers to questions late in the webinar are directed specifically toward the fringe elements of the community who approach the project from a combative perspective choosing to take pot shots at people and Automattic specifically while never doing a damn thing to push the platform forward. While I’ve left names out of the webinar and this post, the message is clear: if you want to have credibility in the community, learn how to be constructive and own the features and elements you want to see.

But the webinar was not a political statement. In fact, most of it was a hands on demonstration of the new twentyten default theme in WordPress 3.0, the custom taxonomy and post type features which bring WordPress into approximate parity with other content management systems, as well as a preview of “The Merge” – the combination of WordPress MU and WordPress.

Thanks again to the folks over at iThemes. If you missed the Webinar, here it is. Sorry, iPhone and iPad users…. it’s Flash. ;)

WordPress 3.0 Preview with Aaron Brazell from WebDesign.com on Vimeo.

For a few days now, I’ve been looking closely at the four major theme frameworks. There are many premium themes. I, in fact, for the time, am using one from Woo Themes that I’ve modified to fit here. However, there are only four that I see as worthy competitors among the elite theme frameworks.

I will be using affiliate links when referencing all of them just because, if you choose to use any of them based on this article, I don’t mind collecting a commission fee. This does not indicate my endorsement of any of them. In fact, quite the opposite. I expect you’ll find me to be a hard, but objective critic of all of them.

The four theme frameworks: Thesis 1.7, Headway 1.6.1, Genesis 1.1.1, and Builder 2.3.11.

Report Scope and Prism

When I went about gathering data on this post, I heard a lot of back and forth from those in the WordPress community about why they liked or disliked each of these themes. Some of the issues were restrictive licensing that flies in the face of the open society that is WordPress. Other things were lingering effects from the Great Premium Theme Pissing Matches™ of 2008. Still others were about how user-friendly the themes were for users. In this report, I put all of that aside and look strictly from the perspective of infrastructure, data, security and WordPress core feature support.

All metrics that have been taken were created equally via a local installation of WordPress (eliminating network latency), with no plugins installed, 10,000 blog posts and 10,000 pages. The data points were taken in the context of a stress test and may or may not reflect actual usage. However, large scale stress is something to be concerned with for any site that is large or plans to become large. How the server handles database transactions, and file load is an integral part of a long term strategy. Each theme was deployed with no configuration changes beyond default settings provided by the theme. The results are fascinating.

This is a seven page article so click through to each new page to read the analysis of each theme.

Photo by icantcu

This was front and center over the past few days when one of our members, Hans, offered his opinions on Facebook’s new HipHop for PHP product. We have already expressed our intent to help make WordPress compliant with HipHop, something that will be beneficial to major WordPress sites like TechCrunch, Mashable, VentureBeat, WordPress.com, the NFL Blogs, the NY Times blogs, the Cheezeburger network (LOLcats, FAILBlog, etc) that carry large amounts of traffic. I hope to be able to consult with some of these organizations on moving into a HipHop system once my head is wrapped around it and WordPress is compliant.

Photo by Josh Hunter

Hans is an extraordinary developer. I have never met him personally, but his depth of knowledge on issues of security and scalability is downright frightening. He offered his own opinion of HipHop on the mailing list and so I’m going to pick on him a bit:

This HipHop thing is interesting, perhaps in much the same way as HipHop music: it feels like a hack. — And I mean that respectfully in both cases; I like hip-hop music, and appreciate how it pays homage to R&B roots, remixing/reinterpreting them, etc; and I think that the idea of taking one language and building it out to something else is also something I should support. After all, I’ve embroiled myself in code generation tools (e.g. Propel) that are operating on the same philosophical groundwork. But I also believe that there’s a general rule like “if you need code generation, there’s something wrong [in your design or in the tools you've chosen or ...]” … so those tools also feel like hacks.

In all of life, there is an evolution that happens. One iteration of something becomes better with improvements over time. This has happened on a micro level inside PHP. Without PHP 3 there would be no PHP 4. Without PHP 4, there would be no PHP 5. Ben Ramsey talked about this evolution before Christmas.

Why is it a hack to improve upon the tools used with a language? Is it a hack to use Memcached with PHP? Is it a hack to run on nginx instead of Apache or to implement FastCGI? All of these are third party software or extensions outside of PHP. So how is HipHop any different?

That’s all fair, but I feel like the problem here is that somewhere a long, long time ago, Facebook *must* have realized that they were going to have scaling problems. Long before they started having a problem, someone *must* have thought “maybe a compile-at-runtime language isn’t the right solution here”. I guess to me this cross-compiler is just a public way to admit that PHP is not the right tool for the job, but they’re stuck with all these developers that only know PHP so it was somehow cheaper to engineer a way to change PHP to C++ than it was to retrain developers on C++ (or, probably more realistic, Java).

I responded in that conversation with an only slightly edited response. While I appreciate, and always have appreciated, his frank, honest, high level view of PHP, web security, web applications, etc., he strikes me as somewhat naive and puritanical.

What I can say is *I*, along with dozens of other technology people in and out of DC, in and out of PHP, never look at our initial ideas as scaling ideas. We look at them as ideas and experiments to see if they have legs. In fact, I’d go so far as to say it is counter-productive to think about scale before thinking of concievability (is that a word?).

There’s a reason why Rails (God help us) is popular. It’s a great prototyping tool. You stand up an app quickly and let it into the wild to see if it has legs. Does it go? What are the market influences? What are the
pros and cons? Do we have to adjust?

After a concept is proven, then a solid dev team with solid tech leadership brings in their expertise to see if the idea can be built into something sustainable. As a sidebar, please take a read of Brad Feld’s very awesome
post from a few years ago “The first 25,000 Users are Irrelevant“.

My point is, it’s silly and a waste of resources for startup people to start thinking about how big they might get maybe 5 years down the road. I think you’d find out that, in most cases, successful technology, web-based companies happened by some dumb luck. Twitter. Facebook. Name-the-popular-app. Dumb luck.

Hey, I’d even argue that when too much comp-sci brain energy goes into an app, you get things like Wolfram Alpha. Cool. But useless. And not nimble enough to actually do the scaling necessary to need all that comp-sci engineering prowess.

Balance, my friend. Balance.

Facebook (and others) start with PHP because PHP is fairly ubiquitous and easy as pie to drop into production. However, there is a point of no return where you are committed to PHP and that’s where HipHop comes in.

Personally, I wish we had HipHop when I was at b5media. We had a ton of scaling problems with PHP and we were running fully clustered Apache servers (25 deep, if I recall), sharded MySQL across 6ish database servers, and we had massive I/O bottlenecks. We ran eAccelerator and Memcached and had squid-based load balancing and damn if Grey’s Anatomy or the Oscar’s didn’t pin our entire network on more than one occasion. What could have happened with an alternate to opcode caching. What could have happened if I had resources to put on developing C++ binaries of our frequently used PHP libraries.

I’ll tell you. It would have rocked. We were already committed to PHP. We were already committed to WordPress. And when the company started, we were all volunteer resources. There was no assumption that our idea had legs or I think everyone on the team would have quit our jobs immediately and put everything into building that company. It took a year to get there.

This is, for better or for worse, the way companies get started in the real world.

By now, the news has hit the street about Facebook’s new PHP pseudo-compiler technology that is looking set to change the PHP world once again. It is called HipHop for PHP.

Here at Emmense, we build on PHP and more specifically, we build on WordPress. The PHP community as a whole continues to innovate the language and Facebook has been a longstanding member of that community. WordPress stands on the shoulders who have gone before, and there are certainly instances of large-scale installs of WordPress that could stand to use some acceration.

It is our intention, here at Emmense, to support the Facebook HipHop methodology where appropriate. We will be exploring the use and implementation of this technology in the days and weeks to come and will be working to build solutions that leverage it in the WordPress world for our clients. Where possible, our work will be conributed back to the WordPress core where appropriate.

While we expect that many more service providers will likely leverage this technology, we want to continue to lead in the WordPress community in an ever-open exchange of ideas between the PHP and WordPress communities.

Below is a video of the unboxing. And of course, you can order the book today from Amazon and I hope you do. If not for the book, to support my efforts. Thanks to everyone who has stood by me during this process!

The conversation came to an issue that I’ve only marginally thought in great detail about. I had made the comment about how I am potentially looking to leave the DC area because, as I put it, it’s not my scene. I feel like a square peg trying to be fit into a round hole. While I certainly have political views and will sometimes voice them, my life does not revolve around politics, policy and advocacy as it does in Washington. In fact, when pressed to explain my feelings around why I dislike DC, I described myself as a regular guy wanting to live a regular life in a regular town.

Defining that more explicitly, I appreciate town like Baltimore, where I was raised and lived most of my life, because it’s filled with people who go about their normal everyday lives. No one is trying to “save the world” as seems to be the case in DC. Certainly, there are people and companies (hopefully many) who take a balanced position in life to be good stewards of the earth, energy and the planet. Certainly, many are socially conscious in how they live their lives. But it isn’t an all consuming agenda such that you find in DC.

I love Austin too. Why? Well, it is the self described live music capital of the country. On any given night, from my experience, it is not difficult to find bars that have a good live music set that is original and that doesn’t carry a cover charge. Outside of a handful of live music venues (DC9, 9:30 Club, Velvet Lounge, Madames Organ to a degree, Rock and Roll Hotel, etc) it’s hard to find a burgeoning music scene in DC.

Even with sports, which consumes a fair bit of my life, it’s hard to find supporters of the home team. No one, it seems, is from DC. They all came here with an agenda. You have to go out to Maryland or Virginia to find real hometown fans.

This is not my scene. This is not what I like. I am an entrepreneur because, first and foremost, I want to make money. When I made a break from my former corporate job, it was after becoming aware of how much my employer was billing our customer for my services and realizing that if that was how much I was worth, I could damn well do that on my own.

But that’s the crux. As entrepreneurs, our general purpose is not to do social good (though there are exceptions). Not that there is anything wrong with that. There isn’t. But entrepreneurs get our kicks from building something. From doing something. And of course, from making money. Who starts a company with the intention to not increase profit margins? You show me that entrepreneur, and I’ll show you an entrepreneur who will fail within a year.

There, of course, is a balance. Like Geoff, Beth and Kami are doing at Zoetica, there’s a balance between making money and doing good. The more I had this conversation with my friend, the more shallow I realized I sounded.

But as I thought some more, the more I realized that doing good is not something you do. It’s something you are. Based on the integrity and character of the entrepreneur, the decisions that are made, whether geared for profit or for building a product or spinning it up into an acquisition by Google, become decisions made out of the character and integrity of being “good”.

Frankly, the more I thought about it, the more I realized that even what I do as an entrepreneur creating services and products around WordPress, (and yes, even sometimes writing patches for WordPress core itself) is done to make the world a better place. Even writing a book on WordPress and travelling to San Francisco, Dallas, New York, Atlanta, Miami, Chicago and Raleigh speaking to WordPress users, developers and designers is done to extend the platform, thus extending the reach and improving on the largest self-hosted blogging platform on the planet.

Think about why this is important. It’s not just about WordPress. It’s about enabling voices. Giving those who never had a chance to speak before the opportunity to be heard. We’ve heard as recently as this week about the man who used an iPhone app to figure out how to treat his own wounds while buried under the rubble in Haiti.

The Chinese government is so threatened by web technologies, and blogging in particular, that they have banned WordPress.com in China.That is not likely to be lifted anytime soon, especially as the government lockdown and censorship of the Chinese people is thrust back into the limelight with the latest Google-China fallout.

Even the internationalization efforts in WordPress is putting WordPress into the hands of more people in more countries and making it possible for voices to be heard, not only in the United States, but in the Sudan and Kurdistan as well.

As an entrepreneur with integrity and character, even the mundane decisions that go into building a company can be seen as social good. This is not intended to diminish the efforts of those who explicitly set out to do social good, but with the right mindset, the things that make us successful can also make the world around us better.

So as I prepare to write this article with an admittedly slightly inflammatory title, I expect it will cause some controversies – maybe, and perhaps intentionally, it will cause some rancor in the leadership of the WordPress community itself – the ones who set the tone and cadence for the rest of the community. This is not all bad and nobody can ever accuse me of not being consistent in how I approach issues I feel strongly about.

For nearly 10 years, I have been coding in PHP. For the past 4, I have spent my time focusing my energies on WordPress specifically. It seems to me that for software that is built on PHP, then, there should be some consistent crossover between the WordPress community and the PHP community. That natural convergence does not seem to exist however.

Early on, when getting started on the web, I hung out a lot over at the SitePoint Forums. It was there that, through a community of PHP developers of varying skill levels, that I cut my teeth. I knew nothing at the time and there were folks who were much more skilled than me. It was in the PHP 4 era (that era had just begun and has since ended) so there was no such thing as real classes and object orientation. XML parsing became a hot topic during those days as PHP devs wrestled with the best way (they were all ugly!) to parse XML. I was just trying hard to figure out how to connect to a database.

I spent months learning and picking up what I could and contributing back my learnt wisdom to other newbies along the way. The cycle of karma was great as people learned and taught each other.

Shortly after I left SitePoint in 2003, I started blogging (May of 2004). I started on Textpattern but within a week, as my curiosity about this new WordPress platform started hitting my ears, I switched over to WordPress. I joined the wp-hackers mailing list and began immersing myself in the WordPress community. Generally speaking, people were very helpful and I learned a lot.

Eventually, as part of that community, I would lead the technology efforts at b5media where my team was responsible for a very large WordPress farm. Having some of the best and the brightest working alongside me meant that my good understanding of the PHP involved in WordPress, and the event driven nature of its core, would increase to maybe very good.

Today, my business is WordPress. I just wrote the WordPress Bible. I do WordPress consulting. I run all my blogs on WordPress. I speak at WordCamps all over. Heck, I’m organizing WordCamp Mid-Atlantic again this year. I love the WordPress community.

During the writing of the Bible, Keith Casey, my friend and also a top developer in the PHP community (He works with Marco Tabini of PHP Architect – if that doesn’t give him street cred, I don’t know what will), offered to review anything I wrote along the way. I took him up on it even though I already had editors including a very WordPress-specific technical editor. My thinking? Having someone from the greater PHP community look at my code for the WordPress world can only make it better.

My question is, why doesn’t the rest of the WordPress world do this as well? We, as a community, can only be better by embracing the greater PHP community. We can learn things from them. They can learn things from us. Of course, the greater PHP community is going to scorn WordPress for remaining PHP 4 compatible when PHP 4 is end of life and I think that point has validity but that’s not the point. I think both sides can agree that WordPress has its way and it is not likely to change its philosophy on this soon.

However, what about the rest of the converging community? Why do WordPress people not participate in the major PHP conferences like Tek-X or ZendCon? Why was Beau Lebens the only WordPress guy that I’m aware of that attended any of the 7-conferences-in-14-days-roaming-conference CodeWorks?

Why is it that when WordPress developers are asked to speak at these events, they look down their nose in scorn (I can think of two specific incidents that have been related to me)?

Hey, if we’re going to have a war on PHP coding ability, I’ve got to side with the PHP coders of the world, not the WordPress coders. If we’re going to have a war on extensible platforms, well, I’ll probably go with WordPress.

My point is really simple: The WordPress community needs to abandon this concept of elitism and isolationism. Yes, isolationism only makes you isolated. Over the past six months, I have come to appreciate the greater PHP community more. I’ve rekindled my love for that community and the karma and learning that comes from it. I’ve discovered new things about PHP because I’ve opened my horizons again and got outside the WordPress box. Fortunately, by doing so, I can apply that knowledge and karma inside the WordPress world as well. It’s sort of like finally getting that water after being parched and thirsty for so long. It’s refreshing and gives new energy and drive.

So in 2010, I will continue to work inside the WordPress world to try to influence change. My code will reflect that change. I’ve abandoned PHP 4 (but again, that’s beside the point) and won’t work with it in my own work, plugins, etc. I hope to make a major announcement regarding some crossover and convergence in the next few weeks as well.

To the PHP World: Understand that the WordPress world is different. You already know this. We are a PHP 4 world for a reason, like it or not. We need some understanding. We also have our feelings on GPL and open source which don’t always jive. Work with us. Help us be better.

To the WordPress world: Get outside your comfort zone and embrace the leaders in the PHP world. I already mentioned Keith. Add Marco Tabini, Ben Ramsey and Cal Evans to the list of people to pay attention to.

Notably, I mentioned that WordPress 3.0 would be going to PHP 5. This was based on conversations I had with a core developer which I now realized I misunderstood. Kinda. WordPress will probably not be dropping PHP 4 support in WordPress 3.0 but as core developer Mark Jaquith suggests:

Some things already require PHP 5, like time zone support or oEmbed. There are no plans that I know of to remove PHP 4 support in 3.0 “” last I checked we still had 12% of WP installs using PHP 4.

I see more of a natural and gradual deprecation of PHP 4. We’re very much open to making new features require PHP 5 if it would be a pain to make them PHP 4 compatible.

As a PHP developer, I am on board with calls for PHP 5 support. PHP 4 has been end of life (EOL) since August 8, 2008. That basically means that there will be no more releases, no more security patches, no more nothing. It’s done. Stick a fork in it. However, as Matt mentioned on stage at WordCamp NYC this weekend, there are still 12% of WordPress installations using PHP 4 hosting. He breaks that down as approximately 2M installs, the size of a major American city. More precisely, that’s approximately the size of Philadelphia.

This is not to defend WordPress development. I’d leave Philadelphia behind in a minute if I could get access to real object oriented PHP, reliable XML parsing, better HTTP transports and so much more. Yes, Philadelphia… I just threw you under the bus. That’s for signing Mike Vick. However, as Mark suggests, increasingly more features are being added to the core that require PHP 5.

oEmbed, which will ship in WordPress 2.9, requires XML or JSON parsing. XML parsing sucks in PHP 4. JSON ships by default in PHP 5.2. It is easier to backport JSON support to PHP 4 than try to engineer XML parsing for PHP 4. Some in the PHP community feel like backporting a PHP 5 feature to PHP 4 disincentivizes PHP 5 movement. It may, I’m not here to argue that.

Time Zone support is handled via the PHP class DateTimeZone, a PHP 5 class. Of course, on PHP 4 hosts, the user simply has to set the UTC offset (say, UTC-5 for Eastern Standard Time) manually. Graceful degradation.

I personally was one of the first people to write code for the SSH2 portion of the one click automatic upgrade feature. I, of course, did not go very far with it, but I was the one who first took a stab at creating that.

It is not worth it for PHP developers to throw mud at WordPress developers and the PHP 4 requirement if they are not willing to write code to make it better. Writing code does not, of course, mean that your feature will be incorporated. But this is an open source project. If you want to see new features, and the developers have indicated willingness through not only words, but also action, to include PHP 5 features, then you need to be the champion of those changes. In other words, you need to write the code, submit the ticket and state your case. Even if you can’t write the code, open a ticket and be a champion for the case.

Effective arguments, however, do not include holy wars over PHP 4 or PHP 5. Effective arguments do include security, usability, and feature requests that reflect “must have” features. Is it plugin territory or should it be a core feature? Why? State your case.

I will admit not being overly active in the ongoing development of WordPress. I have client work built around WordPress, so that takes up most of my time. Understanding that, I also have no room to throw mud unless I’m willing to step up and write code too. It’s sort of like voting. If I don’t bother to go vote, then I can’t complain about my elected officials.

If you want to see change in WordPress, be that change and put your words into action.

It’s now November and almost everything is in the bag for me. I’ve written the book with an average of 20-30 pages per chapter. I’ve gone through Author Review (A.R.), more commonly called “editing”. I’ve taken screenshots. Wrote code. Sifted through pages and pages that have so many changes, from three different editors, that the page appears to bleed. I’ve survived. Sometimes barely. I want to talk about the process of writing that book.

Writing a book is as much mental as it is emotional. Everyday, you evaluate what you have to get done, how much time you have to get it done, and consider the tone and voice in which it is written. I noted in my announcement that I would take on extra work to compensate for the lack of full-time pay the advance money would turn out to be. This became the most difficult part of the process, as it would turn out.

Early on, I spent a tremendous amount of time being very precise and intentional in how I wrote. It was a very slow process but I was pacing myself. I had 4 deadlines at 25% increments that were a month apart (except the last one). I could afford to be deliberate and intentional and pace myself. I had nine chapters to write in 30 days. Done. The first deadline was no problem, but it was a definite time investment.

The second deadline approached in late August. It was the 50% deadline and nine more chapters were due. By this time, I was heavily invested in the two client projects – a corporate redevelopment of Navstar, a federal IT service provider in Northern Virginia and TheCityFix, a WordPress MU/BuddyPress-based project for EMBARQ, a major non-profit in DC. Both of these projects were lagging behind as I went about being meticulous about my book. So when the 50% deadline came, I had my chapters but I was delayed on my clients.

Putting the book on the back-burner at the beginning of the 75% deadline, I spent time catching up on client work. As a week turned into two, and then three and I had not been able to start on the 75% deadline, I had mornings where I would have nervous and mental breakdowns in the shower. I had no idea how I could do it all. I was under intense pressure to do and I simply did not know if I could do it. I hid it well, but exactly one week before I had to have another nine chapters turned in, I began that process of writing those nine chapters. I told my clients I was unavailable. I locked myself away for 12-16 hour writing marathons. At 8pm on the day of my 75% deadline, I turned in my last chapter – a marathon effort that began 7 days before. I headed to the bar for a beer.

We got started on the process late, so although Wiley agreed to push back the 25%, 50% and 75% deadlines to compensate, the final deadline had to stay fixed at October 14. Two and a half weeks. I took a bit of time off to go back to client work because I knew I’d be going to Orlando to keynote IZEAFest, and had intentionally took advantage of the group rate that IZEA had negotiated to get a few extra days in sunny Florida. In theory, I could write the rest of the book by the pool and enjoy the sun. Good idea, but then the wifi was ridiculously poor and I lost six days in the two and a half weeks I had to finish things up.

I came back from Orlando looking at the same situation I had with my 75% deadline – 8 days to go, 9 chapters to write. Up until this point, I had made every deadline even if I was unofficially granted a few extra days here or there if I needed it. I never took those extensions. My editor was firm on the 100% deadline though. It must be done. (She ended up giving slightly in the end but I couldn’t take her up on that because I was leaving for Vegas and Blog World Expo on the day of my final deadline. There was no way to be in Vegas and take advantage of a few more days to write!)

Miraculously, as I flew at 37,000 feet on Virgin America en route to Blog World Expo, I was submitting my final chapter and screenshots. Thank God for wireless internet on flights! I made it. Done. Complete. Breathe.

When I got back from Vegas, however, my editor told me she needed me to rewrite a chapter (or significant portions of the chapter). Sighing heavily, I did just that addressing the areas of concern she had. Then the deluge of chapters began floating back to me for A.R. I had to sort through every single chapter, rewriting some portions, approving code changes from Mark Jaquith, my technical editor, wording and grammatical changes from my copy editor and other generalized suggestions and changes from my lead editor.

I was told that the edit process is grueling. That it is painful. That I better have thick skin. I went into A.R. expecting the worst. Fortunately, it was a fairly painless process. Perhaps after the marathon sprints and my inherent instinct to trust the people around me to make me look good, I rolled with the process. These people make me look good! While I accepted almost every suggestion from all three editors, there were times I vetoed. As the author, I have that prerogative to a point. Generally, however, I trust these people to help me through. It was not as bad as I expected.

Emotionally, I was numb. The book took a toll on me. In most ways, the toll is good. In other ways, perhaps not so much. I still will have to proofread the final product in December and will have a week to do so, but this process is all but over. However, I’m still numb. Does a man achieving what seemed so difficult to do give him an emotional outbreak, as we see when sports teams win the big championship, or does it make us look at life a little more soberly and say, “Wow… I did that. Crazy. Now what?” For me, I think it’s the latter.

From a business perspective, The Navstar project has been wrapped up for almost two months now. TheCityFix is all but wrapped up. When you’re writing, you don’t have time for business development. So now I’ve hit the reset button and rebuilding again. The buzz around the book has already generated enough leads that I don’t think I’ll be hurting for work.

From a book perspective, I can’t wait for this thing to come out. It is available on Amazon on February 15th and you can preorder it now. There will be a book launch in Baltimore and Washington, likely. I will undoubtedly be traveling to many WordCamps next year, including our own WordCamp Mid-Atlantic (which I co-organize). Next time I write a book, however, I will write it about something I want to write about and not something I’m qualified to write about. (kidding).

To aspiring writers, I say:

• Find your groove early. Don’t waste time on stylesheets (every publisher provides a style guide). That’s what the editor is for.
• Roadmap your book so it’s on paper. Most publishers will require a table of contents before you start. It’s for your good as well as theirs.
• Have thick skin during the editing process. Your editors don’t hate you even if their markup seems like they do. They have your best interest in mind.
• Have an agent! The agent is there to help navigate through the business process. Sure, they take 10-15% off the top, but they can often get you more money and more concessions. It’s sort of like don’t ever go to court without a lawyer.
• Write because you want to write. You’ll never make it rich on writing (unless you’re Thomas Friedman, and even then, you’re probably making money from speaking engagements because of your writing).
• Figure out the environment and mode you need to be in to effectively write.
• If you need to stop because you’re mentally exhausted, stop… because you’re mentally exhausted. It doesn’t help your writing to be doing so in a robotic, bleary eyed way.
• Most of all, have fun! Writing a book is a hard process, but so rewarding. If you treat it like work, it will be work. If you treat it as a way to channel your energies, you’ll have more fun doing it. :-)

By and large, this release is a plugin developers release with lots of new APIs and abstraction. However, there are significant additions for theme designers and users as well. As a result, unlike previous iterations of this article (I do one for every major WordPress release), I’m going to break this down into sections for each kind of feature.

Themes: the_post_thumbnail()

Theme developers have a new piece of functionality that have become extremely popular in themes these days. As blogs have evolved from journal form into entities that can be very magazine-like, the use of thumbnail images has also grown. Typically, this layout is achieved through the use of custom fields that must be manually created and populated. No more!

As of WordPress 2.9, if you use the built in image uploader, then WordPress handle this for you. Theme designers that wish to support this feature can add the template tag the_post_image() to their themes to achieve proper placement as required by the theme layout. The template tag can optionally take a “size”, which is one of the WordPress default sizes: thumbnail, medium, large, etc. If none is provided, it defaults to your preset thumbnail size.

Example:

Conveniently, if a theme is enabled for post thumbnails, the only “feature” currently offering this support in WordPress, then a new “meta box” will be displayed on the Write screen allowing you to assign a post image.

Themes: Register Support for WordPress Features

Editorial Note: Since this article was published, the code has changed to refer to post-thumbnails, not post-images. As a result, function names have also change. The code and examples included before reflect this change. Sorry for the confusion and sorry specifically to theme devs who have implemented the_post_image() feature already. Just change it to the_post_thumbnail()

This may seem to be an obscure feature, and typically, it’s pretty simple to figure out what I’m talking about just by looking at the header. In this case, it’s a bit more obscure because it suggests a feature that is introduced in WordPress 2.9 and then only for a very niche purpose. I can see this being built out over time, and plugin authors can supply their own use cases.

The concept is simple. If a feature exists “” in the core, the only use case is for the thumbnails I described earlier and it is called ‘post-thumbnails’ “” then a theme can declare support for the feature using the add_theme_support() function in the theme functions.php. It can only be declared in this file and it requires a feature be assigned a name. As I mentioned, with WordPress 2.9, there is only one feature that is named and that is post-image. Plugin authors can provide their own new functionality using the require_if_theme_supports() function.

Themes would then enable support for the feature by including the following in their functions.php file.

We’ve used the function_exists() check on the add_theme_support() function to ensure backwards compatibility with WordPress installations prior to WordPress 2.9. Similarly (and possibly confusingly in this context), before you would have to check for the existence of a plugin by using a function_exists() or class_exists() piece of logic and loading it if the class or function did exist, but now there are on/off switches to get it done.

Users: The Trash Can

On Windows, they call it the Recycle Bin. On Macs, it’s the Trash. In both cases, the feature exists to help people recover from accidental deletions. We have all had those moments where we nuked something we had no intention of nuking. With WordPress, accidental deletions have been permanent. In WordPress 2.9, everything is recoverable now with a new Trash feature. When you delete a post, page, category, comment, or any bit of content, it is moved to the Trash where you can decide whether to pull it back at a later date.

The Trash Can view. From here, content can be restored or deleted permanently.

Trash collection is done every 30 days by default, but it is possible to change this by editing your wp-config.php file. Add the following to your config file to change trash collection to every 7 days. Modify as needed.

Users: Image Editing

One of the hot new features in WordPress 2.9 is image editing. Now don’t get me wrong. This isn’t Photoshop. And it only support basic functionality at this time. However, image editing will allow bloggers to crop, scale and rotate images from right within WordPress. From the media library, you can edit images by clicking the Edit link under an image, and then clicking the Edit button on the individual image page. This brings up an interface like what is shown below.

The WordPress 2.9 Image Editing Screen

Users: oEmbed

oEmbed, as described at oEmbed.com, is a specification that allows media providers like Flickr, YouTube and others to provide data for consumer applications like WordPress about media. So by including an Embed (Use the File uploader and choose “From URL” and paste the link to the page that contains the media, not the media file itself) in a post or page, WordPress can retrieve the relevant specs on the media file and formulate a properly formatted embed accordingly.

Below is an embed of one of my Flickr photos using oEmbed.

Below, is an oEmbedded YouTube video (Original video removed so here’s the Iron Man 2 Trailer).

If you don’t want to use the GUI for this stuff, you can simply wrap the URL to the media page in embed shortcode tags like this.

The list of supported oEmbed sites in WordPress are as follows:

• YouTube (via oEmbed)
• Blip.tv (via oEmbed)
• Flickr images and videos (via oEmbed)
• Hulu (via oEmbed)
• Viddler (via oEmbed)
• Qik.com (via oEmbed) “” never heard of this site, but it was listed on oEmbed’s website, so”¦
• Revision3 (via oEmbed)
• Google Video (via an internal handler)
• PollDaddy (via an internal handler)
• DailyMotion (via an internal handler)

That said, plugin authors can add new providers if they want by using the oembed_providers filter or override altogether with the WP_oEmbed->providers property.

Plugins: Custom Post Types

One of the strengths of Drupal has been its ability to have multiple types of contents contained in objects that all look alike to PHP. WordPress has supported a variety of content types as well, but it has not been nearly as flexible making WordPress a blog platform with some additional support for pages and attachments. Technically, the only post_types that WordPress has supported have been post, page, revision and attachment. While it has technically been possible to add new post_types (like podcast, mp4, or tutorials – they could be anything, really), it has been a chore and required plugin developers to handle quite a few moving parts in order to make it all work properly.

No longer. Plugin authors now have API to register new post types, opening up the possibility for even more creativity and uses for WordPress.

get_post_type()

The get_post_type() function can only be used in the Loop. It returns the type of post a post is. Keep in mind, I’m using post loosely. All content in WordPress is kept in the posts table thereby inheriting the name “post”, but post is also a kind of content that is associated with blog content (as opposed to page which is a pseudo-static page, attachment which is information about an image or file uploaded with the media uploader, etc).

get_post_types()

The get_post_types() function will return a list of all types of post content. By default, this will be post, page, attachment and revision. Refer to the source code for optional arguments that can be used to control what kind of data is returned.

register_post_type()

As a plugin author, you can use this function to create a new post type. The first argument is the unique handle you want to assign to the post type – let’s call it podcast – and the second argument is an array that contains additional elements. The key one here is an exclude_from_search, which by default is set to true. You actually probably want to set this to false unless you really don’t want this additional content searchable. See below for example usage.

There is currently no user interface for post types. There is a patch in for UI that will likely be included in WordPress 3.0.

Plugins: Comment Meta

There has been a variety of meta tables in WordPress. Meta tables, like usermeta or postmeta, are database tables that contain information about the type of data that is stored in WordPress. It allows plugins and WordPress to assign metadata, such as user roles and capabilities, to pieces of data thus extending that data. Now, there is a comment meta table as well.

Though it is unclear how plugin authors will seek to use this table, the fact that it is available is a major deal as it essentially provides meta tables for every piece of content in WordPress now.

Plugins: Metadata API

With the addition of a comments meta table, it has become effectively redundant to duplicate functions throughout WordPress. You have a get_post_meta() function that does the same thing as a get_usermeta() function except they query data from different tables that also look identical except for the data stored in them.

In WordPress 2.9, there is an entirely new Metadata API that can be used to retrieve data from any of these meta tables.

The add_metadata() function takes a meta type (‘comment’, ‘post’, ‘user’, etc), the ID of the content type, the key and value of the metadata and whether the information should be unique or not (true or false).

You can also use update_metadata(), delete_metadata(), get_metadata() and update_meta_cache() for further wrangling. Refer to wp-includes/meta.php for full documentation.

Themes/Plugins: Theme System Modification

A lot of messiness has been eliminated in WordPress 2.9 theming. For one, new template opportunities exist. Now, instead of looking for a template file called category-x.php, tag-x.php or page-x.php, where x is the ID of one of those types of content types, it will look for these templates second. The first template that is now looked for is based on the slug. So if you have a category, tag or page called foo, the first template to be sought after would be category-foo.php, tag-foo.php, or page-foo.php. If none of these templates exist, then the ID-based template file is looked for.

Additionally, plugin developers can register new directories for themes to be located with the register_theme_directory() function.

System: Database Repair Script

The database occasionally needs a good spring cleaning. Other times, the database needs a repair. WordPress ships with a new script that will do just this. It is housed at /wp-admin/maint/repair.php but in order to use it, you need to create a new (or modify if it already exists for some reason) constant in wp-config.php.

System: Minimum Requirements

PHP 5 is not required yet. That’s coming in WordPress 3.0 will be increasingly implemented over time. But MySQL requirements have been boosted from MySQL 4.0 to MySQL 4.1.2.

Bonus coverage

Other interesting things in WordPress 2.9.

• JSON compatibility, before only beneficial to PHP 5.2, has been backported for use in WordPress
• New ‘Undo’ button when using the Visual Text Editor
• A new sanitization API (with functions like esc_html())
• The emoticon system can be altered using the smilies_src hook. :-)
• Bulk Upgrading of plugins
• Filesystem optimizations pertaining to FTP/SSH etc.
• rel=”canonical” for single posts and pages aiding in SEO
• Minify Admin CSS making for quicker (and smaller) page loads
• Bunny Tags and Jeromes Keywords Importers removed

I call bullshit. Here’s why.

The current security paranoia is around an exploit that has already been fixed! That’s right, it was known and fixed two releases ago. The problem is, the people complaining about WordPress’ security are running old software. They didn’t bother to do the responsible thing and keep their blog up to date!

See, WordPress has two different types of releases. Major releases (2.5, 2.6, 2.7, 2.8, etc) provide new features. These releases keep the software innovative, bringing new functionality to bloggers every 4-6 months. Security releases (2.8.1, 2.8.2, 2.8.3, 2.8.4, etc) are arguably more important than major releases because they keep you safe!

Bloggers who ignore these security releases do so at their own risk.

And because of that, when you are hacked, I will charge you an assload of money to fix you up! Believe it.

There is nothing more I want to do on a holiday weekend that also happens to be my birthday weekend, than to fix peoples blogs who didn’t bother to take care of themselves. It’s personal responsibility. Oh, I’ll do it. You won’t like the bill, though.

If you’re using WordPress 2.7+, as said loudmouth blogger was, it’s so simple to keep things up to date with the auto-upgrade button. WordPress even informs you when your version is out of date and provides a direct link to the upgrade page. If you ignore that, it’s not my fault… it’s yours.

For clients hosted on my servers, you are up to date. Why? Because I make sure of it. For the rest of you, do your part, so I don’t have to. Because my part will be making your blog secure, but it will also be sending you a sizable invoice.

Cheers, and happy Labor Day!

However, more recently, as I’ve just reached my 50% writing deadline, I’ve thought more seriously about going on the road next year after the book goes on sale. (It’s slated currently for Feb 22, 2010 and you can pre-order the book now on Amazon for $31.49
– aff).

So here’s the deal. I am working on a sponsorship that would provide me a vehicle for a round-the-country 2-3 week book tour in late March, early April. I would like to visit 12-15 cities around the U.S. and Canada. Ideally, these are cities where there are a core of WordPress users and, ideally, where there has been a WordCamp (this denotes interest in the topic). Some of these cities might be:

• Washington, D.C.
• NYC
• Boston
• Toronto
• Nashville
• Columbus
• Chicago
• Dallas
• Denver
• San Francisco
• Los Angeles
• San Diego
• Seattle

Each city needs to have a host who can organize the event, take care of expenses, etc. I would like to be able to host an open bar/reception time as well so sponsors probably need to be raised. Don’t get me wrong, this type of thing is probably not a break-the-bank kind of event. We need a venue (bookstore likely), venue (reception), maybe sponsors, my expenses, and someone to get people out.

If you’re interested in hosting in these or other cities, send me an email at aaron@technosailor.com.

That’s how the process of coming to be the newest author for Wiley Publishing seems to have gone, even though the initial contact was only in late April.

Back then, I received a mysterious email in my inbox asking if I would be interested in writing The WordPress Bible. Fascinated, I immediately responded back and the conversation began.

We have had an agreement in principle for several weeks and now that the contract is official, I feel comfortable talking publicly about the deal – though the details of the deal will remain undisclosed.

I’m excited about writing this book. As many of you who have been with me for these more than five years know, I began the process of writing a book with my friend and colleague Jeremy Wright back in 2005. Honestly, I don’t think either of our hearts were in that book and we amicably agreed with the publisher that we wouldn’t complete that project. Sort of a shame in itself, but all for the better.

That project gave me a little window into the life of an author. Overcoming writers block. Roadmapping chapters. Communication at all time with project editors. Stylesheets. Deadlines. All that jazz.

At that time, I was much less mature as a writer so it was a huge challenge to write effectively and for an audience. At that time, I was a much more free-spirited author writing often elaborate (and possibly poetic) prose which might not have been the right fit for a book of that nature. Today, I still am the best damned writer around (kidding) but know when to turn it on and off and how to write an effective 4000 word article or a 140 character tweet.

Today, I approach The WordPress Bible with some fear and trepidation. Currently, the book is marked at around a cool 700 pages. And oh yes, it has to be done in October. Yikes!

What this effectively means is that for the next four months, I will be spending monumental amounts of time doing nothing but writing. I’m considering disappearing to the mountains once a month for 3-4 days just to write.

During the process, I am going to continue to work with my clients to deliver valuable WordPress solutions for their businesses. In the past week, I have secured 3 more clients that I will be able to work with over the next few months.

I want to thank Stephanie McComb at Wiley for believing in me and reaching out to me in April. This will be a great addition to the Bible series. I also want to thank Lynn Haller from Studio B for helping me through the process and running valuable interference during the negotiations. Anyone looking to write a book should reach out to her to represent you. Authors should usually have agents and she’s a great agent.

I can’t wait for this book to hit the shelf. It’s going to be an invaluable resource for WordPress users, themers and developers of all range of skills and will be a “must order”.