WordPress 3.0 arrived in 2010, bringing change not only to the software, but to the development process and project structure. Commit access was opened up and all these changes shaped how the project works today. WordPress’ philosophy — deadlines are not arbitrary — was seriously challenged.
In January 2010, Dion Hulse (dd32) received commit access during the 3.0 release cycle. In the post announcing Dion’s access, Matt outlines a new goal for the project:
One of the goals for the team in 2010 is to greatly expand the number of people with direct commit access, so the emphasis is more on review and collaboration. Right now commit access is tied up with being a “lead developer,” of which we’ve always found a small group of 3-5 works best, but now we want commit to be more a recognition of trust, quality, and most importantly activity, and something that can dynamically flow in and out as their level of commitment (har har) changes and decoupled from the “lead dev” role.
This new approach and decoupling commit access from the lead developer role signaled a big change when every patch went through either Matt or Ryan. There was a need to extend trust to contributors, without necessarily giving them leadership roles within the project. While there were no formal rules, several contributors received commit access: Ron Rennick (wpmuguru), focused on multisite, Dion focused on HTTP, and Daryl Koopersmith (koop) worked on front-end development, while Andrew Nacin (nacin) was the codebase generalist.
As well as a symbol of trust, extended commit access meant that tickets and bottlenecks were cleared quickly. When lead developers got distracted by life and work, Ryan Boren carried the load. New committers reviewed and committed tickets.
April 13, 2010 was WordPress 3.0’s release date. Similar to prior releases — despite having a deadline — development focused on scope and headline features, rather than meeting the date. Three main features were defined in the scope chat: merging WordPress MU with WordPress, menus, and a new default theme to replace Kubrick.
Merging WordPress MU with WordPress came for several reasons: WordPress MU was difficult to maintain, 95% of the code was the same as the main WordPress codebase, and Donncha had to manually merge new features post-release. Because WordPress MU hadn’t gained attention from plugin developers, it felt separate from the main WordPress project. To give users a clean upgrade path, WordPress MU merged with WordPress.
Ron Rennick, a longtime MU user, assisted with the merge. He and Andrea, his wife, had used WordPress MU for years for their homeschooling blogging network. His script turned a WordPress install into a WordPress MU install. He reverse engineered his script to bring MU functionality into WordPress, ensuring a way to convert a single WordPress install to a Multisite install.
Ron ran a diff [footnote] A diff is a comparison tool that compares the difference between two files.[/footnote] against the WordPress MU code, looked for differences in the codebase, and merged them into WordPress core. Ryan Boren and Andrew Nacin cleaned up the code. Ron also merged features absent from WordPress MU in plugins, such as domain mapping — a feature originally developed by Donncha.
Plan A was to allow users to upgrade to WordPress Multisite with one click. “The reason we decided not to do that,” says Ron, “is that a lot of the shared hosts would not have been happy if their users could just take any WordPress install, click a button — without actually knowing anything about what was going to happen — and convert it over to Multisite. The decision was made to actually make it a physical process that they had to go through.” To change a WordPress installation into Multisite, WordPress users have to edit wp-config. They need basic technical knowledge.
Terminology was one of the biggest headaches surrounding the merge. In WordPress 3.0, the project decided to move away from the word “blog,” and instead refer to a WordPress installation as a “site.” More and more people were using WordPress as a CMS, so the “site” label felt more appropriate. However, in WordPress MU, the parent — example.org — is a site, while the subdomain blog.example.org is a blog. With WordPress MU and WordPress merging, which one was the site? An individual WordPress install, or a WordPress install that hosted many blogs? WordPress MU became WordPress Multisite, but that wasn’t the end of it.
To complicate matters further, WordPress MU had a function get_site_option, which gets options for the entire network, and get_blog_option which gets options for individual sites. The functions, therefore, don’t relate entirely to the user interface. That was just one of the functions that caused problems, as Andrew Nacin noted.
Custom post types and custom taxonomies were two big changes in WordPress 3.0. The default content types in WordPress are posts, pages, attachments, revisions, and nav menus (from WordPress 3.0), and the default taxonomies are categories and tags. In WordPress 3.0, custom post types and taxonomies were given a user interface. So instead of being restricted to just posts and pages, developers could create themes and plugins that had completely new types of content for users, such as testimonials for a business site or books for a book review website. This opened up totally new avenues for theme and plugin developers, and those building custom sites for clients.
Menus were the big user-facing feature for WordPress 3.0. At the time, it wasn’t easy for people to add navigation menus to their websites. Menu plugins were popular, so much so that it was obvious that the feature met the 80/20 rule. (Would 80% of WordPress users take advantage of the feature? If yes, put it in core, if not, keep it in a plugin.) The menus ticket was opened in January 2010. The first approach was to create a menus interface similar to the widgets interface. By mid-February, however, little progress had been made. Proposals competed on how menus should work. Ryan and Jen contacted WooThemes to discuss bringing their custom woo navigation into WordPress core. This was just days before the planned feature freeze on February 15, 2010.
WooThemes’ custom navigation made it easy for users to add menus to their websites. Developer Jeffrey Pearce (Jeffikus) worked with Ptah Dunbar (ptahdunbar) on the core team to modify WooThemes’ code for core, and to prepare core for the feature. At the time, core updated jQuery to match the version WooThemes’ theme framework used. The original WooThemes codebase created new database tables for the menus. As a general rule, WordPress avoids adding tables to the MySQL database. Instead, core developers used custom post types — existing core functionality.
However, Jeffrey found the time difference challenging. Jeffrey is based in South Africa; core development work happens mostly on US time zones. Development chats took place at 20:30 UTC, which was 22:30 in South Africa. Additionally, Ptah and Jeffrey kept missing each other on Skype.
An environment in which everyone had a voice and an opinion wasn’t something that WooThemes was used to in their development process. Adii Pienaar, co-founder of WooThemes, described the process as excruciating. One of the main points of contention was that WooThemes had originally put the menus in the center of the screen with boxes to add menu items on the right-hand side. WooThemes had invested time into designing it that way, but the menu interface was flipped around to match WordPress’ left to right interface convention.
The menu integration was one of the first times that the project had worked directly with a commercial business (other than Automattic). While the process was not always completely smooth, both sides benefitted from collaborating. WordPress got its menu system. While not exactly the same as the menu system that WooThemes created, it accelerated development. WooThemes got the satisfaction of seeing its code used by every WordPress user. Not everyone felt that WooThemes received adequate credit, though Jeff didn’t share this viewpoint. “Just to have our name on the contributors’ wall — that to me was good enough,” he says. “It’s nice just to be able to say, I built a part of WordPress. No one can ever take that away from me. That was recognition enough for me.”
WordPress 3.0 ended up being a huge release, and while menu discussion continued, launch was delayed again and again. By April, the core team was still sending around wireframes — discussing whether menus should be pulled from 3.0. The release candidate kept being pushed back. Matt reiterated one of WordPress’ key philosophies:
Deadlines are not arbitrary, they’re a promise we make to ourselves and our users that helps us rein in the endless possibilities of things that could be a part of every release.
Feature-led releases meant delays. Menus caused the hold-up with WordPress 3.0, with prevarication over the user interface and implementation. The final release was packed full of features that included the new menus, the WordPress Multisite merge, custom post type and taxonomy UI, custom backgrounds and headers, and an admin color scheme refresh. Any of these features could have been pushed to the next release, but there was no willingness to do so.
One of the more controversial changes in WordPress 3.0 was a new function called capital_P_dangit. This function ensures that the letter “p” in WordPress is capitalized. People felt that WordPress was messing with their content — that this automatic correction was the start of a slippery slope. For some, it was overbearing pedantry, for others, censorship. WordPress has no business changing what people wrote. Some saw it as incommensurate with the project’s core freedoms: openness, freedom, and community.
Most importantly, the filter broke URLs in some instances. This was reported before WordPress 3.0’s release, but because the filter had already worked well on WordPress.com, it wasn’t fixed immediately. For example, a user reported that his image, named “WordpressLogo_blue-m.png” was broken because it had been renamed to “WordPressLogo_blue-m.png.” Upon upgrading to WordPress 3.0, other users — those with folders with the lowercase “p” — had the same problem. As well as folders, URLs with the lowercase “p” were broken. Hosts saw an uptick in support requests. “When 3.0 arrived,” says Mike Schroder (dh-shredder) of Dreamhost, “we had a deluge of support with broken URLs due to capital_P_dangit() applying to all content. This was a particular problem because it was popular among customers to use /wordpress as a subdirectory for their install. We helped customers with temporary workarounds in the meantime, but were very happy to see the issue fixed in 3.0.1.” Mark Jaquith added a fix, but many contributors believed WordPress should never have broken users’ websites in the first place.
The capital_P_dangit function isn’t the only WordPress function that filters content. Other filters include emoticons, autop, shortcodes, texturize, special characters, curly quotes, tag balancing, filtered HTML / kses, and comment link nofollows. From the core developers’ perspective, capitalizing the “p” in WordPress didn’t actually change the meaning of the sentence, except in edge cases such as, “Wordpress is the incorrect capitalization of WordPress.”
Core developers became frustrated by the hyperbole around the filter and the time spent arguing about it. In a comment on Justin Tadlock’s blog, Mark Jaquith said:
Calling corrections censorship is absurd. It is no less absurd when the capitalization of a single letter is called censorship. There is actual censorship going on all around the world at this very moment. I’m damn proud of the fact that WordPress is being used to publish content that makes governments around the world afraid of the citizens who publish it. I’m incredulous that people are making a fuss about a single character (which is only one of dozens of automatic corrections that WordPress makes). It’s free software that is easily extended (or crippled) by plugins. If the thought of going the rest of your life without misspelling WordPress it too much to bear, you have an easy out. Take it, take a deep breath, and try to pick your battles.”
A website Mark created reflects the position of many of the core developers on the capital_P_dangit discussion:
While this had all of the hallmarks of a bikeshed, there were some procedural issues that community members felt ought to be taken seriously. Whether the WordPress software capitalized the “p” in WordPress or not, the method by which the function was added to core broke accepted procedure: no ticket was opened, no patch uploaded to trac. The code was simply committed. For some, this set up an “us vs. them” mentality, where some core developers could commit code as they saw fit, while everyone else in the community was subject to a different process.
Despite these development snafus, with WordPress 3.0, the platform matured, making “WordPress as a CMS” a reality. It also introduced a new default theme for WordPress, ushering in a new approach with new annual default themes. Gone was Kubrick, with its bold, blue header. The new theme, Twenty Ten, showcased WordPress’ new menus feature.
WordPress 3.0 ushered in changes to the project and the development process. It opened up WordPress to a new generation of people who became increasingly active. Over the coming releases, some of those committers would take on leadership, both in terms of development and in the wider community.