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.

As one of the many working stiffs who can access the internet from work but has to share a connection, I would like to make a request of the corporate world at large:

STOP REQUIRING FLASH TO VIEW YOUR SITE!!!!!!

Everything I look at on the net while at work has to go through a server in northern CA, which doesn’t have Flash capability and probably never will, because it would be even slower if the 250 people using it were allowed to view bandwidth-hogging all-Flash sites. With the economy being what it is, bandwidth costs being what they are, and connection power needing to be split at most offices, I’m not sure any company should be upping the ante this far in the name of pretty pictures. And the defense that people can look at it at home isn’t too great, either, since DSL is out of reach of more working stiffs than web geeks want to admit, and Deity-of-Your-Choice only knows when it might creep into affordability.

So, please do what you used to do, and keep your non-Flash site online after the upgrade, instead of routing us to a page exhorting the wonders of Flash and attempting to bully us into downloading it. (Baaaa.) You’ll widen your audience with very little effort–and hey, aren’t non-Flash sites easier to maintain?