getting seriously pissed off with mantra

Unknown to me the primary blog has been down all day because of a Mantra theme problem in WordPress.

When I got in from my roadtrip, around 5ish, I checked the NAS and the servers; every component was up and running and looking good.

I validated the webservices by checking the geekblog and it looked and responded normally.

I checked my main blog and was surprised to see a blank page. Nothing. Just a big slab of visual white noise.

I checked the MySQL database and it looked good and responded to a dummy query normally.

I checked the WordPress admin page and it came back straight away. But as well as the usual admin things, it displayed an error message I hadn’t seen before:


So something, somewhere, was telling the database to pull a theme (or, importantly, a part of a theme) from a directory that didn’t exist (and no theme directory has ever been located in ‘(‘ as far as I’m aware).


So I switched to the current view (had to knock up a header with text, based on the old header I made for Mantra).



Now I could just reinstall Mantra (and I may well end up doing that), but I’m a bit fed up with the issues I’ve been having with the blog theme.

I’ve just upgraded WordPress from 3.7.1 to 3.8.

Then, mindful of the last bunch of errors, I ran a feed validation against the blog’s self-generating RSS feed and the Feedburner RSS feed.

Both passed (with the same YouTube-related minors).

Very curious.

I need to think about this.

In the meantime I’m going to leave the design on the temporary version, while I ponder.


When I got in this morning the NAS was overloaded again.

2am – having been up since 5am the previous day – is not the ideal time to start fiddling so I just recycled the NASs power.

Before I crashed out at 2.30am, I upgraded the NAS operating system.

I’ve just disabled some NAS services that I enabled at the start of the week – we’ll see what effect that has, if any.

I’ll look in greater, more methodical depth, later today after my road trip.

raiders of the lost awkward

I applied a patch to the RAID controller on the NAS a few days ago.

Twelve hours later. part way through a volume sync, the RAID controller got its knickers in a right knot.

As a result of its panic-fest, the RAID controller gobbled up 100% of the available RAM and then assumed 100% of the CPU.

These unplanned events effectively locked up everything behind my router/primary firewall.

The NAS squeaked out an email to me that it was in trouble.

I remote-accessed the NAS, intending to kill the rogue processes, but although I could authenticate on to it, the device had insufficient processing power/CPU to allow me to step in and intervene.

When I got home, I powered off the NAS and booted the device back up, which restored everything once more.

After another volume sync (I have the NAS set up as a RAIDed device), I performed a controlled shutdown and restart.

This brought everything back up correctly, after the previous power-off/start up.

With hindsight (I have 20/20 hindsight sometimes), I should have performed a controlled shutdown/restart after applying the patch to the RAID controller.

But I didn’t.

Oh well, I’m learning.

If you’re interested in the architecture, this is how things currently look:

The NAS has 2x 1Tb discs.
Server #1 has 4x 2Tb discs
Server #2 has 4x 2Tb discs


fed right up (feeds full of feed)

What did you do lunchtime today?

I converted a spreadsheet from a 24.8Mb monstrosity, to a 72Kb pussycat.

And I debugged the entire WordPress .php application, and the Mantra theme.

I started out debugging just the Mantra theme (let’s not talk about the spreadsheet, that’s a work thing).

But when I’d finished I kept thinking ‘Is that it? Really? That’s it? There isn’t more?’

So I began working my way through the WordPress .php stack.

Actually, I found hundreds of .php files with blank lines outside the begin/end .php markers.

(blank lines outside the <?php – ?> switches are usually the causes of feed failures)

I could have been clever.

Or lazy.

Same thing, really.

I could have opened the feed-related files in the includes folder and put this code in:

$out = ob_get_contents();
$out = str_replace(array(“\n”, “\r”, “\t”, ” “), “”, $input);

But I didn’t want to do that, because it wouldn’t have answered the unasked question.

Coding my way out of the issue wouldn’t have actually told me how many instances of the issue there were.

And now I know.

Because I fixed them.

Fixed them all.

By hand.

Because I am a geek.

feed the birds (tuppence a bag)

Because Young Mister Masher started me thinking about the main blog’s RSS feeds…

And also because Young Mister Punctuation added further fuel to my thoughts…

I have been thinking.

Yeah I know.



The main blog generates a direct and an indirect feed.

The direct feed is the generic The indirect feed is a Feedburner product.

What happens with the indirect feed is that Feedburner sucks in the direct feed address (and all traffic on it) and spits it out via an indirect address of

I ran the blog’s direct RSS feed through Feed Validator and it passed, but with two minors.

Then I ran the blog’s indirect RSS feed through Feed Validator and it failed.

Stone dead.

What the?


I scratched my head.

How is it possible that a website feed can generate an acceptable RSS content, but when that feed is parsed through Feedburner it generates a fail?

Anyway, I stopped scratching my head, fired up an FTP session and renamed the plugin folder, then ran the Feed Validator sessions again.

The results for the direct feed came back with a pass and one minor.

The results for the indirect feed came back with a big fat ‘F’ again.

I reconnected the plugins folder and inspected the .php for each one, looking for rogue spaces outside the < and >.

None found.

Then I checked theme-functions.php looking for the same thing.

None found.

Then I checked theme-functions.php in the child theme I have running.

None found.

I switched themes to a native WordPress template and revalidated the RSS through Feed Validator.

The directly generated theme came back with a big green tick and one minor.

I pinged the indirectly generated theme through Feedburner, made myself a mug of hot chocolate and then revalidated the RSS for that one.

This too came back with a big green tick and one minor.

A theme problem, then?

Seems likely.

I changed the theme to a low-impact design I used for a year or so, checked the four plugins I use were good to go and revalidated the directly generated feed.

Green. One minor.

I pinged Feedburner and revalidated the indirectly generated feed.

Green. One minor.

(At this point I had a thought: I bet these changes will make Mister Masher’s Yahoo feed reader’s cup overfloweth)


I downloaded the current version of the Mantra theme (the one I use as my default design template), unzipped it, and uploaded it to the server.

Then I switched the theme back to Mantra and ran the feed validations again.

Both failed.

This is pretty conclusive evidence that there’s a .php problem somewhere in the Mantra product.

Although the problem doesn’t stop RSS publication through the direct feed, somehow it becomes a bigger issue when the direct feed is parsed through Feedburner – and stops the indirect feed from working.

So when Young Mister Punctuation said his feeds had not been disrupted during the last server change, this was (probably) because he is subscribed to the directly generated feed. I need to check this.

And when Young Mister Masher declared feed issues, the last time I did a server swap, it was (probably) because he was subscribed to the Feedburner feed. I need to check on this too.

So, to wrap this up for now: I have switched the theme away from Mantra, to the one I validated both feeds successfully against about half an hour ago.

I have switched the four plugins on.

I have just run a final feed revalidation against both feeds and they both passed (with the same minor).

I will start to debug the Mantra theme tomorrow.

Oh, and I’m unconcerned with the minor that shows up.

It’s the same one every time, and it is related to YouTube’s encoding of embedded content.

So a big fat ‘meh’ to that one.

Tomorrow I’ll debug.

Tonight I’ll drink hot chocolate and watch an episode of Outnumbered.

studio laptop / bsod update / driver ? (v2.0)

This evening I resolved the unexplained driver issue that the studio laptop Device Manager has been shouting about.

Apparently it was a Conexant D330,HDA,MDC,v.92 Modem Driver, for a…


For a 56k modem.

Anyway, I was clearing boxes out of the studio (not sure why, when I’m probably going to move house again, in the next four months), when I came across my box of drivers.

The sixth disc of drivers that I tried reinstalled the troublesome rogue and Device Manager has now stopped shouting at me and settled down.


So, the studio laptop seems to have stopped getting BSODs (because I removed 90% of its content).

And I’ve resolved the drivers error.


I have also just patched CentOS, so now I have to perform a restart on web and email services.

But you won’t notice this, because I’m being cunning.



geeky, but with extra music

I’m trying to make musical decisions; I suppose this is a bit like being a teenager all over again.

I’m trying to build my ultimate playlist of driving tunes (that is, tunes that inspire me when I’m driving).


No, it’s not.

Just one wrong choice and the whole list is buggered.


Not worth the temporary disc-space it’s written on.

Anyway, here’s my current driving playlist.

Always looking for good suggestions.


studio laptop / bsod update / driver ?

Well, migrating everything, even the 60Gb of music, from the studio laptop seems to have had a beneficial effect.

No more BSODs.

However, I still have the unexplained drivers issue, in Device Manager:



It’s a puzzle.


There has been no new hardware installed in – or connected to – the laptop.


And yet the message is that a Modem Device driver is either incorrectly installed or in conflict.








When I delete the hardware, in Device Manager, the error message goes away.





But on reboot, the same conflict appears.

I’ll get the Windows drivers disk out of the box in the spare room.

Any day now.

bsod / overdue admin


The studio laptop has thrown me two non-fatal BSODs in the last month.

The first thing I did after recovering from the first, was to check drivers. The system identified a USB driver issue, which I had a feeling I have known about for some time.

But I can’t resolve it, right now, because the box of drivers is upstairs, fully packed away, in one of the large cardboard boxes in the spare bedroom.

After the second BSOD (happened about three weeks after the first) I looked harder at the studio laptop’s hard disk.


Space was a little tight, with over 75% of the 149Gb hard disk full.

And I know that having a hard disk close to its maximum can lead to non-fatal BSOD error messages.

I don’t have MS-Office on the studio laptop, but I do have quite a bit of editing software (the very large Sony Vegas Pro, and the almost equally chunky Cubase, as well as a handful of smaller audio and video editing tools and file conversion utilities).

I can’t remove the editing tools/conversion utilities, obviously, because this is why the studio laptop exists.

But I have deleted a metric fuckton of completed video and audio edits, because they were already stored in audio and video project libraries on the NAS.

Then I looked at what else was left behind.


Slightly under 60Gb of music.

Slightly under 60Gb of music which is already backed up on the NAS.

So why is it on the hard disk of the studio laptop?

Because iTunes needs a local drive to work with.

And because of that simple rule, all of my music files have been stored in c:\documents and settings\[username]\my documents\my music\itunes\itunes music

Why is the music stored in that tediously long address?

Because the studio laptop precedes the arrival of the NAS by several years. And because although I have backed up my music library to the NAS every week, I have never migrated the iTunes functionality off the c:\

Because I have never got around to mapping a drive to the NAS.

Well all that is changing.

I have mapped z:\ to the NAS. I have given the mapping the appropriate permissions to read/write to the appropriate NAS directory.

And as I type this, iTunes is copying 7,081 songs from c:\etc to z:\my music\itunes



I say ‘hopefully’ because I won’t know if this has worked until I plug my iPod in, and it (hopefully) syncs with the library in the new location.

And I won’t be able to plug my iPod in to sync it, because moving 7,081 songs from c:\etc over to z:\etc is taking a really really really long time. Even though I’m directly connected to the router via Ethernet cable, and the router is directly connected to the NAS via Ethernet cable.

Oh well.

Fingers crossed that it all turns out alright, eh?

Anyway, when I’ve been able to validate that this musical migration has been successful, I will return to the hard disk of the studio laptop and delete the 60Gb of music.

And then I will start running serious diagnostics on the cause of the non-fatal BSOD.


There is method to my madness.



Well, it worked.

And then I deleted the (now) duplicate music files on the c:\

And the studio laptop is down to 39.9Gb occupied and 109Gb free.

And it’s a lot quicker than it was.

And the iTunes migration plays nicely from the z:\ drive that I mapped to the NAS.

So yay!

intricate transference

Or, to put it another way:

Migrating a WordPress-based TLD website and an integrated sub-directory-based phpBB forum, when each entity is driven by their own MySQL databases (and keeping the content intact, obv)

I thought I was going to have a bucketful of problems with this experiment, but amazingly it turned out to be problem free (if a bit fiddly on the phpBB side of things).

  • Backup the website MySQL database
  • Backup the forum MySQL database
  • In one operation, backup the website content (including the forum content)
  • Transfer the backups to a local disk or drive
  • Create the virtual host and DNS Server/zone file creation for the TLD website (as per here)
  • Copy the website and forum content in to the virtual host folder (nb: this will create the forum subdirectory)
  • Create the TLD MySQL database (copy the database name and username from the wp-config.php file in your WordPress root, and give the new database the same password as the old one) nb, you may need to edit the wp-config.php file to reflect the new address of the MySQL database, typically it will be ‘localhost’ for the new database, but the legacy address in the wp-config.php file might be different
  • Create the Forum MySQL database (copy the database name and username from the config.php file in the phpBB root, and give the new database the same password as the old one) nb, see above re addressing the MySQL database correctly
  • Import in to the new TLD the MySQL database from your backed-up TLD database
  • Import in to the new Forum the MySQL database from your backed-up forum database
  • Change the routing (may be a zone file edit) in your domain registrar’s control panel, to point the TLD at its new host
  • Wait
  • After a while, when the new host is active, your TLD website should be exactly as it was, though the forum won’t work yet, but don’t worry, we’re nearly there…
  • Go in to your WordPress control panel and access the wp-united product that you have used to integrate the website with the forum
  • Ignore any scary error messages that might be shouting at you
  • Click on ‘change location’ under the phpBB location heading, and navigate to your forum root and click on the config.php file
  • That should make the scary error messages go away. It should also (though this might take five minutes) sync the design and user details in your website and your forum (assuming you’ve set wp-united to do these things)

Your website content and design (and any bells and whistles you may have built in to it), and your forum content should be intact, and you should have successfully migrated your website and its integrated/interfaced forum to a new host with zero downtime, and no losses.


For email transfers, see this post (but you should give it a few hours, before you do, to allow the host change to propagate, before you config your new email users on your new server).