We’re Back…

…and we’re running WordPress.

It’s been an unpleasant time.  We’ve had to get the RAM upgraded in our server, but we don’t really know what else has gone on.  In the process of the troubleshooting, we migrated the site from Drupal to WordPress, and I think we’ll be sticking with WordPress now.  Drupal was great, but the site is really just a blog now, and that’s what WordPress does best.

I used to love it when things went wrong. It was an excuse to sit poking a computer for hours on end. Now, I want to leave the computer behind at least some of the time, and go outside. Being tied to the computer, and working late trying to fix a broken database isn’t as much fun as it used to be. I hope things keep working, and don’t need too much maintenance for a while now.

Drupal Image Module – Server Falls Over After Uploading a Batch of Images

Update3: The problem never stayed away, and got worse. I tried upgrading to Drupal 6.x, but our hosting has such an old version of MySQL that we can’t run Drupal 6.x. I then tried a fresh installation of Drupal 5.x, fetching the current version of every module we need, and enabling things gradually. So far, things are pointing at the search module again, but I only stopped the problems by deleting the search module and emptying all the search tables. Disabling the module didn’t stop lots of locked processes updating the search_index table. We’ll see how things go from here, then.

Update2: Running without the Image module didn’t fix it – it happened again. We now have the Image module enabled again, and a few other modules disabled. PathAuto is included in this lot, as I’ve heard it can have performance issues with a lot of paths (we have over 1,000). If things stay stable this way, I’ll probably try updating PathAuto to the latest version and enabling it again.

Update: This turned out not to be the case at all. The next batch of images I uploaded were ok, but the next after that caused the same locking problems without the search module running. I’m just going to abandon the image module for now, and maybe have another go when we upgrade to Drupal 6.x.


A GoogleFood post – there’s probably nothing of interest here, unless Google has brought you to this page when you’re trying to work out why Drupal keeps making your server crash, run very slowly, etc, after you’ve added a batch of images.

I think I’ve got to the bottom of this problem now, so I’ll post this in case it’s any help to anyone later.

I was using Drupal 5.x, with the Image module. I was importing images by uploading them using FTP, then using Image Import to grab them from there and add them to the site. When doing that, the first time you view the images after adding them, Drupal has to generate the various sized versions. I always went through viewing each image to let this happen, because it took a while, so I didn’t want visitors wondering why their browser was hanging if they happened to be the first to view an image.

At some point while doing this, the site would stop responding, and I found I couldn’t even stop/start MySQL through my host’s control panel. I had to log a call with them to get things going again. The first time, the database wasn’t working properly afterwards, and some repair was needed.

After a few more tries, I found that what was happening was that MySQL had a number of locked processes. The number of locked processes seemed to grow until it was too much for the server, and MySQL would stop responding. After a while, Apache usually died too.

From the look of it, it’s actually the Search module causing the problem when it tries to index the images. Generating the different sizes is a slow process, and can make things look like they’ve hung for a while, but nothing is locked, so it gets there eventually. Once I disabled the Search module, though, I could set lots of images off to generate sizes, without locking any tables. phpMyAdmin was good for troubleshooting – use Show Processes to see what’s going on. Try disabling the Search module, and see if the problem goes away.

We now have to decide if we can do without the Search module or the Image module. I think Search will probably be the one to go, replaced with a Google search box.

Redesigning our Redesigns

Note: this article is out of date now – it’s not referring to the current design of the site.

Well, anyone who visits reasonably often has probably already noticed that we redesigned again a couple of weeks ago. I’ve finally put aside my dislike of fixed-width designs, and used one. It’s based on the 960.gs implementation, turned into a simple Drupal theme.

The choice of fonts was aided a lot by a couple of articles:

Putting these two together, we’ve picked fonts that should display well on all major platforms, and fail over to something reasonable on anything else.

We’re still experimenting a little with the ads. Just a little while ago, we replaced the big ad block in the top left with a random photo. We like the money they bring, but we don’t want to make the site unpleasant to read, either.

Hope you like it – if not, I hope it’s at least readable and not too objectionable.

Another New Look for PigPog

Another week, another new look for PigPog.

This time, it’s a completely new theme I’ve built, so there’s even more chance that I’ve broken something. It’s all a bit basic, but it feels a bit more like it’s actually ours. I’ve put all the navigation stuff in a couple of reasonably narrow bars on the right, so the content is the first thing on a page.

It’s readable, and shouldn’t be too overloaded with ads, which were two of the problems with last week’s effort. Anyway, as ever, let me know what you think – even if you don’t like it. When it’s a theme built from scratch, it should be a bit easier to change.

A New Look for PigPog

Ever since upgrading to Drupal 5.x, we’ve just stuck with the default theme, with just a colour tweak to make it ours. I finally decided to take a bit of time to look at other themes, and found one I quite liked – it’s called Channel Nine (no relation that I’m aware of to the Microsoft thing). I’ve made a few very small changes to the theme, mainly to change the colours.

The idea of a theme without the standard ‘masthead’ top section was quite appealing, and this one seems to cope nicely with different screen widths, too.

As usual, I’ve tried to check things, but I might have broken something – please comment here if you spot something I’ve missed.