PigPog

I’m fiddling with this custom theme here. Comments don’t seem to be showing up at all, so I’ll try to fix that. I’ll also put some ads somewhere.

I’m also aiming to put tabs at the top of the sidebar, so we can have a few ‘pages’ of information in one bar.

Time to play with JavaScript.

I’ve been playing with a custom theme for PigPog, which moves our ‘Oinks’ (little posts with no real thought behind them) into a sidebar (here, all being well!). It seems to be working ok, so I’ve just activated it for the live site. It’s not as pretty as it could be yet, even allowing for my limited web design skills, but I’ll keep tweaking it. As usual, do pass on any thoughts – it could help the tweaking process.

All seems to have gone smoothly again. I used WPAU to do the upgrade automatically, which worked fine. The new admin interface looks nice, and I’m posting this through the new ‘QuickPress’ feature – a posting form on the Dashboard page. Cute.

It’s ten years ago today that we registered the domain pigpog.com.

We didn’t have a web site on it at first – it was mainly registered for the sake of having permanent email addresses, at a time when a few people were starting to block anything from webmail addresses as likely spam.

The earliest version of the site on Archive.org is from December 1999, when we thought we were funny.

I’ve experimented with a few different gallery plugins for WordPress, so we could host our photos over here, rather than just keeping them all on Flickr.  None of them quite did what I wanted, but I’ve just found NextGEN Gallery, and I’m quite impressed so far. It’s not the simplest to get set up, but there are lots of options, and it gives you a nice simple way of adding photos from your galleries into any post.

I usually upload photos to Flickr, then insert them into posts here to tell the ‘story’ of the day, event, etc., and I still wanted to be able to do that – most other galleries made that difficult. Most others also meant uploading photos one at a time. That’s not too bad if I’ve been out and taken three or four shots, but a bit of a pain if I have ten or so. For events like the Race for Life or the Slimming World Regional Finals, it would have been unusable. I’ve uploaded the Slimming World event photos to NextGEN, and adding 191 photos was quite easy. The upload stalled twice, but each time, just clicking the ‘upload’ button again continued from where it got stuck.

I’ll probably be tweaking and playing for a while yet, but feel free to have a look around the gallery – probably nothing you haven’t seen before if you visit much, just in a different format.

Oh, and it’s also running the random slideshow at the top-right corner of every page.

I just upgraded our installation of WordPress here to the latest version, using the WordPress Automatic Upgrade plugin. All seemed to go pretty smoothly.

It’s just an experiment at the moment, really, but we’ve created a new category here: Oinks.  The idea is to use Oinks for quick simple posts, like Twitter posts, or links.  If a post on Twitter is a tweet, we figured a similar short post on PigPog could be an oink.  Grunts and squealing available separately.

Oinks are formatted a little differently to ‘full’ blog posts, articles and photography – at the moment, they’re in grey text, and indented a little on both sides.  I’ll probably fiddle with that a bit more later.  At the moment, they stand out that way, but if the idea goes well, most of PigPog could end up made of oinks.

When we moved everything over to WordPress (from Drupal), we lost some data.

• All posts lost their ‘author’ setting – for old posts, the site has no idea if they were written by me or Sam.
• Tags and categories – they did come over, but in such a mess that they had to be deleted. There aren’t simple parallels between Drupal’s Taxonomy system and WordPress’ Categories and Tags.
• ‘Static’ navigation – though we’d mostly moved away from that anyway.

We’re trying to go through old posts, editing them to add back the author, and apply suitable tags and categories, but with over 2,000 old entries, we just aren’t going to get around to doing them all. I’ve done quite a few of the recent ones, and I’ll work through some more yet, then start trying to update the most popular posts.

I’ll also have a go at putting in some relatively ‘static’ navigation pages, too. There are some posts on PigPog that a lot of people come to us looking for. We might as well make them easy for people to find. I’ll probably try this over the next week or two.

The photos in the top-right corner of each page are randomly picked from a list. I’ll replace the default ones with some photos of my own soon, too. It will feel a bit more like home once I’ve done that, as that was one of the last things I did to our own custom theme under Drupal – adding a random photo next to the title section at the top of the page.

Beyond that, we’ll try to actually update more often, though that will mean more short ‘blog-like’ posts, with less concern for quality. If the static navigation works, though, that shouldn’t matter too much. We just want to get back to the point where the site is a fun extra to our lives – recently, it’s been taking over, or just ignored. We want it to be part of our lives, but we don’t want it to be our lives any more.

…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.

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.