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!

Well, Flash 10 is out with new features, security updates, and a fix for a Firefox video problem that I never noticed because it only affected Windows, and only sometimes.

It seems a little less stable than version 9 on Linux, at least 64-bit (it’s kind of complicated, because they only have a 32-bit program, so you either need to run a 32-bit version of your web browser, or use a wrapper that will let the 64-bit browser talk to the 32-bit plugin. nspluginwrapper does this for Firefox and other Gecko browsers, while Opera has a wrapper built in). But the annoying part: WordPress’ image upload no longer works.

Current versions of WordPress use SWFUpload to provide an enhanced file uploader. If you don’t have Flash installed, it will just use the standard upload dialog built into your web browser, but then you’re stuck uploading one image at a time — a real pain if you’re making a photo gallery post. Unfortunately for upload libraries, Adobe removed the ability for the Flash API to open a file dialog for security reasons.

So now, you can click on the button, but the dialog never opens. WordPress is tracking the issue in ticket 6979, which mentions that SWFUpload is discussing workarounds, and the YUI Uploader has already released a new version that works with Flash 10.

An update of some sort is likely to happen soon. In the mean time, WordPress users have two choices: hold off on updating Flash, or stick with the browser uploader for now.

Update October 31: SWFUpload has a new version in beta which works with Flash 10, and WordPress is working on integrating the update. It’s targeted for WordPress 2.7, which comes out in a little under two weeks, though the 2.7 writeup lists it as a feature that “didn’t make it” and might be in 2.8. (This seems like something that would affect enough people that I’d hope they would include it, even if it means pushing back the release a few days for more testing.)

There’s also been talk about implementing a file uploader using Gears, which I’d find really appealing if I weren’t 64-bit Linux both at home and at work.

Update November 1: I’ve tested WordPress 2.7 Beta 1 (not on this blog) and can confirm that the fix is included, as I was able to upload two images in one transaction.

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.