If you are a Bad Behavior user, upgrade to version 2.0.14, and you won’t have to worry about WordPress 2.5 compatibility problems. Also on another note, if you have a high-traffic site, Bad Behavior may not be right for you. It might have been my imagination, but I noticed a slight increase in site responsiveness when I disabled Bad Behavior here back when I first learned it had issues with WordPress 2.5. (Additionally, FYI, I noticed a ginormous increase in site responsiveness when I disabled the Text Link Ads plugin!)
Like probably most early adopters and testers of the beautiful1 2.5 version for WordPress, I’ve had a lot of fun checking out what’s new, what’s different, and all of that.
I was particularly excited to try out the new interface for uploading media, which I didn’t have to wait long to do, due to the convention of having a graphic to head each post.
So I chose a picture and attempted to upload.
Then it happened; I apparently had killed the Intarwebs, and WordPress started complaining about “403 Forbidden” errors which neither carried with them any explanation or even showed up in my server’s error logs.
Crap, now what? So I trekked off to the WordPress testers mailing list and sought the help of the experts, and I was promptly taught the ways of tracking down media manager debug information by Andy Skelton (thanks again!).2
And I stared long and hard at that debug information. Something in that smattering of code and status information was the answer to my problem. I compared file requests, file names, and user-agents between the debug code and my server logs.
Then it occurred to me: the uploader is using the user-agent “Shockwave Flash”; could that be the problem?
I scanned the list of blocked user-agents active on my server — it wasn’t listed. Just to be safe, though, I removed the blocks and tried again. Still nothing.
Finally I decided to do what I should have done to begin with — deactivate all of my plugins and try again. So I did, and uploading worked! Hmm, a plugin was at fault the whole time, and it didn’t take much to narrow it down. Upon glancing at the list, I remembered that Bad Behavior3 had a user-agent blacklist.
So I opened up /wp-content/plugins/Bad-Behavior/bad-behavior/blacklist.inc.php and started scanning. Not too far down at all I came across this bit of code:
$bb2_spambots_0 = array(
[snip]
"PussyCat ", // misc comment spam
"PycURL", // misc comment spam
"Shockwave Flash", // spam harvester
"TrackBack/", // trackback spam
"user", // suspicious harvester
[snip]
);There it was!4 Removing the “Shockwave Flash” line allowed the new WordPress media manager to function properly.
Hopefully putting this out into the blogosphere will keep anyone else from re-sending to the Testers email or posting to a WordPress bug report about this issue. It’s an easy fix that anyone can do. :-)
- Specifically the new admin interface! [↩]
- If you want to enable debugging in the media manager, open the file
/wp-admin/includes/media.php, and replacedebug: falsewithdebug: true. Revisit the media manager to see the debugging in action; revert the change to turn debugging off again. [↩] - A great plugin for stopping possibly malicious users from ever even reaching your site. [↩]
- The actual line # within the file was 41. [↩]
