How is WordPress Subversion Organized


There’s some confusion about how WordPress organizes it’s Subversion (SVN) repository. Most SVN repositories are organized into three main directories, as is best practice — trunk, tags, branches.

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.

Remember When I Did Professional Services? I’m Back.

One of the greatest things about being back in startup life is watching our product evolve? Since WP Engine officially launched back in July, it has been a whirlwind of streamlining the product, listening to our customers and the community, growing with our customers needs and, in general, iterating on our offering.

That was 4 months ago. I’m not going to go into our numbers, but I will say we are on a very healthy up-and-to-the-right trajectory. Our customers asked us for an affiliate program. We gave them an affiliate program where they can earn money for every new customer they refer to us.

Then they asked us for a consultant plan, aside from our standard $49 and $99/mo plan. We gave them that, after talking to consultants and asking what they needed and wanted in such a plan.

Many of our customers have since been saying, “Hey, we love what you guys are doing providing a much needed optimized WordPress platform, but… can you help us with some of our custom plugins, themes and WordPress development projects?”

Obviously, I did WordPress consulting for several years. I was able to work on some great projects and work with some great customers along the way. With my book, I was able to reach into other industries and make a name for myself. I have experience with this.

So now, I’m back in professional services bringing my experience as a consultant and applying the strength of a company at my back. Before it was just me. As a result, I turned away a lot of work that otherwise I would have liked to take. Now, I’ve got the support and organization of WP Engine as we expand our offering to, again, meet our customers demands.

Of course, our new professional services offering is not limited to our hosting customers. Even if you’re not one of our hosting customers, I’d love to talk to you about delivering on a project or to enter into a maintenance or other retainer agreement.

So if you have a WordPress project or you need help on an ongoing basis, drop me an email at aaron@wpengine.com and let’s talk about it.

Solving the WordPress Traffic Overload Problem

Anyone who’s been around WordPress for a “Digg effect” or other massive influx of traffic knows that it can be a real problem. From a technical standpoint, the problem is that PHP is entirely loaded into memory for every pageload. That includes the 99% of PHP that is not being used to actually render the page.

On low traffic sites, this problem is not necessarily noticed. It doesn’t have a huge impact. However when there are hundreds of requests hitting a server in a single second, that kind of overhead builds up very fast.

There are solutions to this sort of thing and depending on what the scale of the environment is, some might be more excessive than necessary. The WP Super Cache plugin is a quick solution that will cause pages loaded on WordPress to be cached meaning that if subsequent page loads can pul the HTML from the cache without having to load the overhead of PHP as well, everyone wins. On the more extreme end, server configurations can be made to send requests for different types of content (for instance, images) to specialized servers optimized for that content type.

Very geeky stuff. It’s important to note that WordPress gets a black eye all the time for it’s caching mechanisms and ability to handle the load of a “Digg effect”, etc. In fact, Instapundit Glenn Reynolds is the latest to take a stinging swipe at WordPress and trust me when I say, we heard it loud and clear.

At b5media (where I’ll be leaving as the Director of Technology soon), we’ve had to deal with this as well and have managed to develop really sound solutions to some of these problems. However, for WordPress as a whole, it is a well recognized problem that not everyone can solve by following in our footsteps (or WordPress.com footsteps).

We’re going to do what we can to help solve this problem once and for all as two of our developers, Mark Jaquith and Brian Layman will be mentoring a Google Summer of Code intern to develop a robust caching engine for WordPress. We hope that this exercise will result in a more reliable (and sane!) caching mechanism.

Integrated Caching Solutions will improve WordPress’s speed and reliablity out of the box and allow people to “Digg Proof” their sites without the struggle of installing plugins on a site that is virtually unreachable. (Source: WordPress Google Summer of Code 2008)

Glenn, I hope that the work that Mark, Brian and our intern will be doing will improve the WordPress problem. In the meantime, let me know if I can help you with anything (though I believe you are using Movable Type). It is a known issue and it’s one that needs to be solved and hopefully some steps can be made toward that this summer.