Installing WordPress from the Ubuntu repository: here be filesystem bloat

Since this is the very first post on my shiny new Bootstrap-IT site blog, why not start things off with some of the joys and regrets that can accompany WordPress installations? I’ve built all kinds of WordPress sites but, until now, I’ve always done it the old fashioned way: Get the latest archive from the WordPress web site, upload it to my backend, create a database and user within MySQL (or, more recently, MariaDB), edit the wp-config.php file accordingly, copy the files to my document root directory, and set it all up from the browser configuration page.

WordPress Ubuntu Repo VersionThis time, so I could rely on apt to keep me properly updated and patched, I thought I’d use the WP version from the Ubuntu 14.04 repository.

In some ways, it’s a lot simpler. Just run apt-get:

sudo apt-get install wordpress

You will need to create a symbolic link between your document root directory and the WordPress files in /usr/share/, which should look something like this:

sudo ln -s /usr/share/wordpress /var/www/html/wordpress

Then you will extract the setup script:

sudo gzip -d /usr/share/doc/wordpress/examples/setup-mysql.gz

…and run the script specifying a database/user name (myname, in this hypothetical example), and the blog location. Choosing the right details can sometimes be a bit tricky. Hint: don’t include a dash (-) in your values.
sudo bash /usr/share/doc/wordpress/examples/setup-mysql -n myname localhost

Now point your browser to http://yourdomain.com/wordpress, set things up, and you’re done.

Except that you may find you’re not done. Even if the installation went smoothly, you’ll probably need to add a new theme and some plugins. If you’re planning to do that manually, you’ll have to do it on Ubuntu’s terms, and those terms are, to be charitable, a bit strange. Here’s the thing: for some reason, the setup script created directories containing WP files (or links to other directories) in as many as SIX different places! And, while they often look identical to each other, they sometimes seem to perform very different tasks – at least as far as I can see.

First of all, as I already mentioned, you will have created a symlink within your document root (usually var/www/html/) to /usr/share/wordpress/. The full set of working WP files will therefore appear in both of those locations.

My installation had another wp-content directory in /srv/www/ – this one containing only a directory named localhost – probably the result of my use of “localhost” when running the setup-mysql script. Then there’s a completely NEW set of plugins and themes, etc., in the wp-content directory that, for some reason, makes an appearance in /var/lib/wordpress/. And all that is besides the WP configuration and htaccess files in /etc/wordpress/.

Here’s where things got fun for me. To manually install a new theme, it turns out that I needed to upload it to the themes directory in /usr/share/wordpress/wp-content, and THEN create a symlink to it in /srv/www/wpcontent/localhost/themes/.

sudo ln -s /usr/share/wordpress/wp-content/themes/hiero /srv/www/wp-content/localhost/themes/hiero

Again, this might be due to my choice of “localhost” during setup, but it’s an odd set of hoops to jump through. And it’s made a whole lot more odd by the fact that this workaround will only work for themes, but not for plugins. I suppose those little guys wouldn’t be seen dead in same directory tree as themes. Instead, you’ll have to put their royal highnesses in /var/lib/wordpress/wp-content/plugins/.

I thought that I had a pretty good understanding of the Linux filesystem hierarchy standard – in fact, I’ve taught it a bunch of times as part of LPIC-1 certification preparation courses – but I’m not sure I understand what lies behind this tangled mess.

But what about the comfort of knowing that my package will be automatically kept up to date? The apt-get repo version is WordPress 3.8.2, while the direct-download version is 4.4.1. I absolutely love the Debian software repositories: their tireless good work makes access to really outstanding software both reliable and safe. But it’s not always the best choice.

The bottom line? The post you’re reading right now is part of a blog created using an up-to-date archive downloaded directly from the WordPress site.

Leave a Reply

Your email address will not be published. Required fields are marked *