Installing WordPress MU on a Dreamhost Server

Blandname is currently hosted with DreamHost, and we’ve been here for years. It’s cheap, offers lots of goodies, and one-click installs allow us to easily install and test web-based software. Not to mention that they also support Ruby on Rails, and give you SSH access and the ability to run a Jabber server as well as unlimited MySQL databases. If you are wanting to host your own website then choose a UKservers.

You’ve also probably gathered that blandname is currently running WordPress. Dreamhost Circulo Marketing has had a one-click install for WordPress just like ipage has for a while now, and since it was handy at the time, we went for it.

But things change, and one-click installs often are not enough to satisfy most webmasters, which is how we got where we are today. Since my goal with blandname is to create another multiuser blog similar to what has already been running for years at yottabite, but instead of having one big weblog, we’d like to have multiple subdomains like string.blandname.com, which WordPress MU allows you to accomplish, automatically.

Unfortunately DreamHost doesn’t support WordPress MU‘s subdomains by default yet (you can always send them an email), but we can still get away with subfolders, which is more than good enough for a test.

This guide will require familiarity with DreamHost’s control panel, as well as common Bash shell commands as we will be using SSH.

The first step is to make a test domain for you WordPress MU install. In my case, I navigated to the “Domains” section of the left-hand menu, then to the “Manage Domains” section of the DreamHost panel, and created the new subdomain test.blandname.com. You’ll want to make sure to select PHP5, and enable extra security. This typically takes about 10 minutes to complete, but we still have the database to add, so let’s get to that at the same time.

In the “goodies” section of the DreamHost control panel, select “Manage MySQL”. The default view is to set up a new MySQL database, which is what we’re going to do. Create a unique database name, the subdomain you would like it to use, as well as the data base username and password. Make sure to keep note of all of these settings as we will need them when installing WPMU.

DreamHost will have by now created a folder in your SSH root that will allow you to place files there and start some of the work while we wait for the subdomain to be created and propagate. Login to your server using SSH (you’ll need to use either your DreamHost hostname here or another web address for now – you can use the WordPress Mu domain later). Now we’ll navigate to the new subdirectory that was created when we setup the new subdomain by typing: cd test.blandname.com Change the folder name to whatever is pertinent in this case.

Now that we’re in the correct folder, we’ll grab the latest using the always-handy WGET. Here’s the code:

wget http://mu.wordpress.org/latest.tar.gz

gunzip latest.tar.gz

tar -xvf latest.tar

cd wordpressmu-1.0 (this will probably change, ls -al will tell you the dirname)

cp -rf * /home/YOURUSERNAME/test.yourdomain.com/

cd ..

rm -rf wordpressmu-1.0/

Now we’ve got a clean directory structure in the root of our test domain, and we’re set to go ahead with the WordPress MU installation.

By now the subdomain has probably propagated because DreamHost is getting faster and faster, so using your web browser, navigate to test.yourdomain.com

Next you’ll want to retrieve the soiled napkin, SubEthaEdit file or whatever else it was that you used to jot down the database settings, and plop them in here. They are very straightforward, and this is typically the most problematic so check them twice but have no fear: if you mess up WP MU will tell you, and you can retrieve the settings from the “Manage MySQL” section in the DreamHost web control panel.

The rest is quite simple: you’ll be met with a typical WordPress installation page, but instead it’s for WorPress MU. The first question that needs to be asked is whether or not WordPress MU users will be using subdomains or subfolders of the root WPMU installation. As previously stated, DreamHost currently does not support subdomains by default (I’ve put in a request, here’s hoping), so we’ll select subfolders here. WP MU will have already placed the domain name you will be using in the yellow textfield, but if you had decided to use subfolders instead of the webroot, you’ll want to specify that here as this will affect all links as well as your RSS feeds.

Lastly, we’ll want to name our multi-user WordPress MU blog, and specify the email address that you will use for things like spam reports, and replies to your comments on the parent blog.

Click on that small “submit” button, and let’s see what happens!

Hopefully on the next screen you’ll see this message:

Creating Database Config File: DONE
Congrats! Your WPMU site has been set up and you have been sent details of your login and password in an email.

Click on the link provided, and get with customization, as we’re all done.

Make Prototype.js TINY – Keep Compatibility

Prototype.js is a very popular AJAX framework used when building dynamic websites. You will find Prototype in most Ruby on Rails projects as it is included by default, and for good reason; Prototype.js is a great library that includes a lot of functionality.

Unfortunately it is rather large in size, weighing in at roughly 50KB.

Although many have managed to reduce the file size of Prototype by paring down the code and gzipping the file, we’re going to use an additional tool to approach the problem, one from the Mozilla foundation that appears to work very well – Rhino.

(Oh, in the interest of full disclosure, I am a Java fanboy, having studied at a university that got a lot of Sun funding back in the day. I hope you can see past that and check out this Javascipt hack, I really do.)

An informative quote from the Mozilla page for the Rhino project goes like this:

“Rhino is an open-source implementation of JavaScript written entirely in Java. It is typically embedded into Java applications to provide scripting to end users.”

Alright then, so what you have is a Java bytecode version of Javascript that will work in most browsers.

Sounds interesting, let’s see what we can do with Protoype.js!

I decided early on to use a Rhino tool that I found on the Dojo site that allows me to compile Javascript and make it Rhino compatible. The page give you a brief walkthrough and some examples on how to use the tool, so I won’t need to cover that here in detail.

So we compile our Prototype Javascript file, let’s see what our results are then, shall we?

Before: 47445

After Rhino: 32716

After Rhino and gzip: 9454

So it’s at about 9KB now!

In order to utilize the new file, upload it to the directory that houses your original Prototype javascript file, then any instances of prototype.js in your code to prototype.jgz (zipped javascript).

You’ll also want to change your .htaccess file so that you handle the new script properly by typing pico (or nano or vi or what-have you) .htaccess:

RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} ".*Safari.*" [OR]
RewriteCond %{HTTP:Accept-Encoding} !gzip
RewriteRule (.*)\.jgz$ $1\.js [L]

AddType "text/javascript;charset=UTF-8" .jgz
AddEncoding gzip .jgz

You'll notice here that we're doing user agent detection for Safari. When I did my testing it seemed to be spotty, so what we're doing is falling back to javascript if we see that the user is using Safari. We're still compatible, and the code works everywhere else.