If you installed WordPress more than two times, you know the drill. Download the latest version, unzip or untar, copy config-sample.php into config.php, edit config.php, upload files to your web host, visit new WordPress URL, click “Next Step” a couple of times, while submitting blog name and administrator’s email. After all is done, login with username “admin” and provided random password, go to Options menu, and set things the way you want them to be. Then upload and activate chosen plugins, and then switch theme to something you’ve spent some time searching for or designing.

Overall, the process is very simple and straight forward. And there are rumors that it will be even simpler in upcoming versions of WordPress. It’s all nice and good. But there is something that only you can make better.

If you installed WordPress more than two times, and by now we know you did, chances are you have a certain way of configuring things. You probably use the same administrator’s email. Or want to use a pre-defined password, not a randomly generated one, because you seriously can’t remember random passwords for those 20 test WordPress installations just on your laptop. Now, going through Options, setting things the same every time is boring.

There are, of course, better ways. In this post we’ll see how to automate this task with a plugin. In one of the near future posts we’ll see how to do even better with a custom install.php file.

To get a few ideas for a starting point, let’s look at what WordPress does itself. It uses some defaults for sure, as there are many things that we don’t need to change when we login for the first time. Yes, those are called reasonable defaults, and WordPress has them specified somewhere. Let’s look.

I’ll save you some source code digging and tell you where the yummy stuff is. SQL scheme and default options are in wp-admin/upgrade-scheme.php file, and some initial records, like first post, first page, first comment, and default blogroll are done from wp-admin/upgrade-functions.php .

So, now that we know what WordPress sets for it’s defaults, we have an idea of what we want to change. Let’s pick something simple, just for the sake of the example. Say, I want to use 20 items in RSS by default, not 10. And I want to disable smilies, because most of my WordPress installations are for corporate clients with very little sense of humor. The options I am therefor interested in are ‘posts_per_rss‘ and ‘use_smilies‘. I want to set 20 for the first one, and 0 for the second one.

It’s time to write my plugin. Here is the first version, as small and simple as I cared to make it:

I save this code into local_settings.php file and upload it to wp-content/plugins/ folder. Now I can see a new plugin entry in the Plugins management.

Before I activate my plugin, I want to see the old values. I check the Options->Reading screen and see that Syndicated Feeds -> Show the most entries is set to 10, as in all WordPress installations by default. I also make a test post with a smily in it and check that the smily image in fact appears on my new WordPress front page. And just to be absolutely sure, I look through all options quickly for the values that I’m interested in. Everything is right – default WordPress stuff.

Now I Activate my plugin and rush back to Options->Reading to see the changes. Hooray! The number of items in my RSS feed is set to 20 now. Reload the front page, and I don’t see the smily anymore. It’s pure ASCII stuff – columns and brackets. Quick list of options confirmed that the default WordPress values are now in fact my default values.

A quick beer to celebrate the victory and and a new skill in my toolbox. But wait.. what’s that? Hold on! Oh, no! It seems that I can’t change my default values to anything else now…

I do want to have my own defaults, yes. But I want to be able to change them on those sites that need changes. Like with WordPress values – I can change all the defaults I want. Now, whenever I change the number of RSS items in Options->Reading screen and save a new value, it seems to have no effect. My default of 20 items comes back no matter what I do.

The good thing is that I just started my celebrations, and my mind is still sober. I am quickly enlightened to the fact that those two lines in my plugin are executed on every WordPress page load. I specified no conditions at all.

It’s time for the second version of my plugin. This time, I want those lines to execute only once, when my plugin is activated. How do I tell WordPress to execute those lines at specific moment in time? I need a hook. A quick look at Plugin API and WordPress Hooks sorts me out. It turns out, I am looking for register_activation_hook() function. So, here is the second version of my plugin:

What’s happening here? Nothing much. I put all my options in a function. And then I told WordPress to call this function every time a plugin in the current file is activated.

A test is in order. I go to my Plugins management and disable the old version. Now I go to Options->Reading and change my default value back to WordPress default value of 10. Save it and make sure that it works. It does (because my super plugin is disabled and does not interfere with the balance of nature). Now I upload the new version of my plugin, go back to Plugins screen and Activate it. A quick check with Options->Reading confirms that the value of RSS feeds was set to my default of 20. And I can change it now too. The smily test is also passed and I’m smiling too over a new bottle of beer.

While I enjoy my pint, I have a couple of small ideas on how to improve my plugin. First of all, I want to set default WordPress values back when my plugin is deactivated. This seems like a proper line of behavior. So, here is the third version of my plugin, which adds this important functionality:

For any action there is a reaction. For any activation there is a deactivation. I don’t even have to dig through the documentation anymore. I’m assuming some things exist, and they in fact do. This is one of the reasons I love WordPress so much.

Another round of tests shows that everything works OK. I’m proud enough to show this little thing to one of my co-workers, who immediately spots the problem. You see, this is why you should stick to open source code as much as possible, and show your code to as many people as possible. It’s just so much easier to make your code better this way.

The problem my co-worker noticed is with going back to WordPress defaults. It is true, WordPress sets those values that I use as initial defaults. But those values aren’t necessarily the same when my plugin is activated. So, instead of going back to initial WordPress values, I should return to values which were set before my plugin was activated. To do so, I have to save those values before I overwrite them.

Here comes the fourth version (and final for now) of my plugin:

Whoa! It’s a long one! But I’m just building on the previous versions here. I get the values of the options before I overwrite them with mine. I save them into two other options (‘orig_posts_per_rss‘ and ‘orig_use_smilies‘). When my plugin is deactivated, I revert the changes. And, being a good WordPress citizen that I am, I delete the unused options.

While testing the plugin, the quick access to WordPress options tip comes handy. When my plugin is activated, I can see the extra options in the list of all options, although there is no direct user interface to edit those options. When my plugin is deactivated, I can make sure that the unused options are deleted.

Here, you have it. A quick and easy way to customize WordPress installations without doing lots of boring manual work and without modifying any internals. Next time we’ll see a totally different approach to this problem – a customized install.php file. If you are in a hurry, you can find all about it yourself. I gave you all the hints already.