Those who switched from Movable Type to WordPress did so at a time when the software itself was in flux. May 2004 was the month WordPress 1.2 launched — a release that improved WordPress’ flexibility.
Before WordPress 1.2, developers extended WordPress using “hacks,” a concept inherited from b2. A “hack” was a set of files bundled with instructions on where to insert the code into the b2 core files. In b2, administration happened in a separate PHP file. The b2 user opened a text file — b2menutop.txt— to add the name of the PHP file that they wanted in the menu. When the code ran, the new menu item would appear after the default menu items. To add a hack to the administration screens, the user needed to place the PHP file into the admin directory and add a reference to it in the text file. If the hack output was supposed to appear on the website, the user needed to edit b2’s index.php file to put it in the right place. It was a convoluted process that intimidated users uncomfortable with editing code. Also, it meant that when a user updated b2, they had to save the text file and the index file to ensure that their changes weren’t overwritten, and integrate their changes back into the new files.
The plugin system brought dramatic changes. It uses hooks to enable developers to extend WordPress without having to edit core files. Hooks are triggers placed throughout the codebase that developers use to run their own code and modify the software. There are two types of hooks: filters and actions. Filters were already available in b2 for developers to create hacks, which changed content. For example, by using the_content filter, a developer can modify content under conditions they specify. Actions, which were first added to WordPress 1.2, allowed developers to run code when events happened. For example, by using the post_publish action, a developer can run code whenever a post is published.
The plugin system is an example of Ryan Boren’s influence early in the project. As many other developers’ involvement trailed off, he dove straight in to development. Mike Little recalls how he hadn’t noticed Ryan at first, that he’d been active, but quiet about his contributions. It was the plugin system that made Mike really take notice: “It shone brighter than most of the other things that people were doing. And that’s not to say that people weren’t doing good stuff, they were, but that was a step change. The hook system was a step change in WordPress development, and it was probably the first step on quite honestly making it the superior product that it is.”
The plugin system transformed WordPress for core developers and the wider community. It meant that the core product didn’t need to include every developer’s pet feature, just the features that made sense for a majority of users. Ryan says that the plugin system enabled core developers to implement the 80/20 rule: “Is this useful to 80% of our users? If not, try it in a plugin.” Unlike hacks, which involved editing core files, plugins could be dropped into a directory in a user’s WordPress install. Non-technical users were able to extend their blogs without having to mess around with PHP. The barrier to entry around extending WordPress inched lower.
The first plugin — which is still bundled with WordPress — the Hello Dolly plugin, randomly displays a lyric from the Louis Armstrong song Hello, Dolly! in the top right of the admin dashboard. It was intended as a guide to making plugins. The second plugin was the blogtimes plugin, which generated a bar graph image showing when posts were created over a certain period of time.
Internationalization was another major advancement in WordPress 1.2. From its very beginning, the WordPress community was international in nature. The original developers were from the United States, the United Kingdom, Ireland, and France, and a forum thread from January 2004 shows how international the growing community was. Community members came from Hong Kong, Wales, New Zealand, Japan, and Brazil. With people from all over the world using WordPress, translations soon followed. The Japanese WordPress site was set up in December 2003, only six months after WordPress launched. As WordPress wasn’t yet set up for localization at that time, (Otsukare), a community member from Japan, created a multilingual fork of WordPress. This was an internationalized version of WordPress that people could use to make their own localizations. It was popular among WordPress users from non-English speaking countries who wanted WordPress in their own language. Its popularity emphasized the necessity of internationalizing WordPress. A lack of proper internationalization tools in WordPress could have led many community members to use the fork instead. Maintaining two codebases in this way would have been inefficient and bug-prone.
Ryan used gettext to internationalize WordPress, which he used in the GNOME project. It involves marking up translatable strings with the gettext() function, so that a .pot file is generated containing all the translation strings. Translators translate the strings and generate .po and .mo files for localized versions of WordPress.
To internationalize WordPress, Ryan wrapped the translatable strings with the gettext() function and put them in a format that provided a full string to the translator, which retained context. He went through the code, one line at a time, found everything that could be translated, and marked it up. This meant that when WordPress 1.2 was released, it not only contained the plugin API, but was fully internationalized.
On May 19th 2004 — before WordPress 1.2 was even released with the first official .pot file — Pankaj Narula (panjak), released the first full localization in Hindi using the new gettext method. Following the release of WordPress 1.2, there was an explosion of WordPress translations, including French and Norwegian.
Version 1.2 made WordPress much more accessible and available to a wider group of people. The plugin system turned WordPress from a straightforward blogging tool into a publishing platform that anyone could extend — all you needed was a bit of PHP knowledge. And if you couldn’t write PHP, you still had access to the ever-widening commons of plugins, as developers created new plugins and distributed their code. Internationalized code meant that it was now possible for people all over the world to have WordPress in their own language, and a community of translators quickly grew around the software. Naoko Takano (Nao), who was an early member of the Japanese community, recalls that there were other free software projects that didn’t take translations seriously and that WordPress’ internationalization efforts encouraged her to join the project.