I just noticed that my author pages at wedin.org were pretty messed up and now that I’ve fixed them I figured I’d make some notes about what I did.

The first problem: Giving the admin a nickname that’s the same as an existing username breaks that user’s author page.

I thought it would be nice to give the admin user the nickname ‘isaac’ because then when I commented on posts without remembering to log out the comments would say ‘isaac’ rather than the Orwellian ‘admin.’ Obviously, I wasn’t thinking straight - one should only do serious admin tasks when logged in as the admin. The danger of making a mistake isn’t the only drawback - it somehow confuses WordPress, breaking the author archive page of the user whose nickname the admin uses. This may only happen with permalinks - I didn’t investigate it extensively.

The solution: Set the admin’s nickname back to ‘admin’ (and log out after doing admin stuff!). Or I guess you could promote your normal user high enough to do most admin tasks.

The second problem: Broken author pages for users with ‘@’ and such in their usernames.

Some of my users have registered using their email addresses as usernames. That shouldn’t be a problem - WordPress allows ‘@’ and ‘.’ in usernames, so it should be able to deal with them, right? Apparently not with permalinks turned on. Without permalinks the author page receives an author ID to identify which posts to show. With permalinks the author page receives the author nicename to identify which posts to get. Unfortunately, the WordPress function the codex suggests using to get the author info is get_userdatabylogin(), which wants (duh) the author’s login. The login has things like ‘@’ and ‘.’ but the nicename does not. So, for my users crazy enough to use their email addresses for login names the author page was showing nothing.

The solution: Rewrite the author page to use this query instead of get_userdatabylogin():

$wpdb->get_row("SELECT * FROM $wpdb->users WHERE user_nicename = '$queried_name'");

This should probably be in a cascade of if…else statements so that turning off permalinks doesn’t break the author page.

Let’s say your favorite radio station has an MP3 stream. Unfortunately, your favorite radio show on that station is on at some odd hour. Or you’re just scatterbrained and forget to tune in. You desperately need to record the show so you can listen to it whenever you’d like. Using cron, wget, and a little shell script it’s pretty easy.

Find the stream address

At my favorite station, KEXP, clicking an MP3 stream gives you a .pls file, which contains the stream address. Normally, you’d open this in an audio client such as xmms and listen away. Instead, download the .pls file so you can view the stream address.

Write a script

Here’s an example bash script that records a show with wget, using the date to make a unique name for the show. URL is the stream address you found earlier. LPath is the path where you want to put your recorded shows.


#!/bin/bash

/usr/bin/wget $URL -O ${LPath}radio_show-${Date}.mp3


Save the script to your bin folder as something like “radioshowrec” and test it out - run it for a few seconds, stop it, then listen to the resulting mp3 file.

Setting up the cron jobs

First, make sure your user can use cron. I did this by switching to superuser mode and making an /etc/cron.allow file with my username in it.

Next edit your crontab file by typing “crontab -e” and add a pair of lines like this for each show you want to record:


00 12 * * 1 /home/joe/bin/radioshowrec
00 13 * * 1 /usr/bin/killall wget


The first line starts the recording at noon every Monday. The second line stops it at 1 pm. It will actually kill all of the wgets that might be running - if you plan on having more than one going at once you should figure out a smarter way to stop the recording.

Since the above script makes files with unique names, the files will pile up after a while. Personally, I just want to listen to the most recent show, so I leave the date part out of the script, overwriting the old file every week.