WordPress, Podcasting, and Changes

I’ve been using WordPress and Podpress to set up podcasting sites for almost 4 years now. I loved Podpress… it made it so easy for people without advanced tech skills to still be able to create a podcast of their own (or at least post it to their site and feed).

I stuck with it even during 2008 when there were no updates and the support forums would vanish without warning, partially out of loyalty to a good plugin (and Dan’s a really nice guy), and partially out of regret for my role in the addition of the Podango functionality to podpress.

The challenge is not finding another podcasting plugin to replace podpress — there are several out there that work just fine. The challenge is converting existing posts from using Podpress to using whatever the new plugin might be.

The other drawback is most if not all of the podpress users in my little enclave like the builtin podpress statistics… the instant gratification of seeing that your new episode has been downloaded 500 times within the first half hour of posting it can be addictive, and getting someone started on using a different stats tool can lead to frustration on both ends.

So this is the start of an experiment. I’m going to be testing out Powerpress from RawVoice (mostly because it will work in tandem with Podpress), and see if I can’t figure out a way to easily convert shows that have between 100-300 previous episodes out there.

I’m not in that big a rush, though. The main reason for my wanting to investigate other podcastin plugin options vanished mysteriously about a month ago. My error logs were bloated with podpress statcounts errors (the infamous duplicate entry for key 1 error), literally for a couple of years… until sometime within the past 4-6 weeks.

The errors just went stopped happening. I’m not sure if they upgraded MySQL or PHP on the server where my sites are, or exactly what happened… I do know that the recent Podpress 8.8.1 maintenance release wasn’t what fixed things, because I’ve only installed it on one site, as a test.

But, I continue to explore.

Manually Restoring a Crunchy Database

It’s usually prudent to back up one’s databases fully before transferring a domain from one hosting provider to another. So what do you do when not even that goes according to plan?

I made the mistake of trusting that a full transfer worked, just because the sites and the data on the new location seemed fine. It wasn’t until a few days later, when trying to create new posts, that I uncovered a MySQL glitch.

I’m still not sure what exactly caused the glitch, but on three (possibly four) of the transferred sites, the auto-increment keys were munged, at the very least. At least, that’s the one thing that makes sense from the behavior.

What’s even more interesting is that I ended up taking a different approach to restoring each of the sites.

First site: empty all tables, and restore data from the seemingly incompatible backup. This cleared up the problem, but all of the options from the previous setup were gone, along with a bunch of stats. Not an optimal end solution.

Second site: in order to avoid loss of options and stats, I did a WordPress export of the current site to extract the data needed, then deleted the tables for terms, taxonomy and posts. I recreated those tables using the SQL statements from the Wordpress code from the same version as what was currently running. Once those tables were recreated, I ran the import of the WordPress XML file, and all seemed fine. Turns out the comments were still crunchy.

Third and fourth site: repeate of process for site two, including the comments table from the start.

There are times when all those years spent troubleshooting as a sysadmin pay off.

Lesson learned: never trust what Plesk tells you about your database backup. Go commando if you can (command line interface and mysldump are your safe bets).

Next, to play with DirectAdmin and see if it can give me the same control panel flexibility as Plesk without the same headaches.

The Joy of Customization: mimbo3

I was intrigued when I found mimbo2 last year… it seemed to be the perfect layout for a blog idea that a handful of us had been keeping on the back burner for a couple years: Deep Geeking.

The term “Deep Geeking” comes from a description of what we do when we fall into intense analysis and discussion of a topic; in this case, the source topic was Babylon 5 and what we do on the podcast: in-depth discussion of the episodes and the deeper topics of character and theme. I loved the name, and one of the show’s fans registered the domain for our later use. It was 2 years before I actually got around to setting up a website for it.

I liked the way mimbo2 did article images, and my experience with the way arthemia2 handled images made customizing how I wanted those images to appear using mimbo a fairly easy modification to incorporate as well.

I wasn’t 100% happy with my final look at the time, but it served a purpose.

Then along came mimbo3, and most of the nagging questions I had in my mind about some functionality had been addressed… but the part I liked the most about mimbo2 had been excised completely: article image management.

I may be in the minority, but I like Custom Fields for specific image usage and placement. I like having the option to use one image for a thumbnail and having a different image for an internal article image, if there is one. It’s more interesting, to me personally.

So my challenge was to do some extreme hacking on a child theme for mimbo3 to regain that Custom Field image usage that I adore, while keeping the rest of the layout the same. Since the child theme vintagegreen was close in style to the mimbo2 look I liked and wanted, that’s what I used for my base.

While mimbo3 and its use of child themes seemed as if it would be more work at first, needing to only make changes to a child theme changed my mind about using them… I had been ambivalent about them before, but now I see the upside to them. I don’t know if I’m completely sold on them yet, since I’m not the kind of person who’ll update a base theme frequently enough to need a better solution to keeping my customizations, but I can better appreciate the advantages of them now that I’ve had time to work with them.

Site: Deep Geeking
Theme: mimbo3 / vintagegreen (child theme)