The other night I had to take the MacBook into the Apple store to get it checked out after a toddler-related spill. I got there for my appointment and waited…and waited…and waited….

Killing time with my Android phone felt a bit weird. If I hadn’t needed to stay close to the Genius Bar I could have at least browsed the gadgets and played with an iPad or a newer laptop with a Retina display, or something. There’s only so long you can spend looking at boxes of headphones and cases for devices you don’t own. I briefly considered reading the new Flash comic book I’d picked up earlier in the day, but thought to myself, “Nah, I bet this isn’t supported here.”

Then I saw this on the wall:

Flash at the Apple Store

Well then, I guess it’s supported after all!

I tried out the Chrome beta for Linux on two different computers yesterday. On the first one, Flash worked right “out of the box.” On the second, it wouldn’t even show up in about:plugins. I couldn’t figure out what was different.

  • Both are 64-bit systems running Fedora 12.
  • Both are running the 32-bit version of Flash from Adobe’s yum repository.
  • Both are running the 64-bit version of Google Chrome from the beta download page.
  • I had run mozilla-plugin-config -i to create the 64-bit wrapper on both computers after updating Flash. (A security update came out yesterday.)
  • Flash works just fine in 64-bit Firefox and Opera.

I looked thoroughly at my home computer last night and came up empty. This morning I took another look at my work computer — the one where Flash actually showed up — and I think I’ve found it.

Chrome is using nswrapper_32_64.libflashplayer.so according to about:plugins. The actual file is in /usr/lib64/mozilla/plugins-wrapped/. This system has two symbolic links to that file, one in /usr/lib/mozilla/plugins/ and one in /usr/lib/mozilla/plugins-wrapped/. IIRC Only one of these was present on my home computer.

So I think this will fix it:

ln -s /usr/lib64/mozilla/plugins-wrapped/nswrapper_32_64.libflashplayer.so /usr/lib/mozilla/plugins/

Run the command as root or using sudo.

I’ll check back tonight and update this entry to show whether it worked.

Update: Yes, it worked!

I’ve upgraded to the just-released WordPress 2.5. The new admin interface is very nice, especially the ability to upload more than one image at a time (though I think they might want to test uploading a single picture a bit more [edit: Maybe it’s specific to Firefox 3 beta 4—on uploading one image, it shows the control panel three times instead of just once.] [edit2: Maybe it’s on the Firefox beta, but the Linux version of Flash Player. It works just fine on the same version of Firefox on the Mac.] [edit3: It’s definitely the Linux Flash Player; I tried it with Opera on Linux and had the same problem.]).

I’ve adapted my theme to use new built-in support for Gravatar and optimal titles instead of the plugins I was using before.

All the stuff you’ll see appears to be working just fine so far. A couple of minor glitches with some admin plugins (WP-Amazon takes two clicks to show or hide instead of just one), but no biggie.

There was one issue during the upgrade. I’ve been using XCache for WordPress to improve site performance. I was asked for the XCache admin login & password during the database upgrade. I couldn’t remember them, so I renamed object-cache.php and hit “cancel” on the password prompt, but it seems to have upgraded everything fine.

The one really annoying thing is that the Bad Behavior anti-spam plugin conflicts with the new media uploader (it’s already on the WordPress 2.5 Plugin Compatibility list). There are two issues. First, “Shockwave Flash” is apparently used by spambots, so it was listed in blacklist.php (code 17f4e8c8). Second, it seems Flash is mixing and matching HTTP 1.0 and HTTP 1.1. If I remove it from the blacklist, it trips condition a0105122, which indicates an Expect header appearing in an HTTP 1.0 request. Removing that test allows it to upload, but the test catches a lot of spam…

Edit: I tried out the visual editor again, as it was billed as “it doesn’t mess with your code anymore.” Sadly, it does mess with your code. It disappeared an image in one post, and it still replaces semantically-neutral <i> tags with <em> tags, even when you’ve entered them manually. <em> is for emphasis. When you italicize a book title, you are not emphasizing it. By replacing one tag with the other, it adds inaccurate semantic meaning. This is just as incorrect as using <h5> to get small text instead of using it for a level-5 heading.