Busted by iTunes!

Now here’s something interesting. Apparently a (now deceased) pianist released a series of CDs under her own name that were actually identical to other previously released CDs by other artists!

I’ve had it happen a few times that I would put a rather obscure CD into my computer and CDDB would incorrectly identify it as something else. This is because their key to identifying a CD is the number and length of all of the tracks, which generally is unique, but of course it’s not impossible for two CDs to have the same number of tracks, and for their respective lengths all to match. Out of the 700 or so CDs in my collection, I’d say 10 to 15 of them had this happen when I ripped them in iTunes.

Usually the false matches are so obviously wrong that there’s little room for confusion, but in this case things were different!

WordPress is great, but the documentation leaves a little to be desired…

Alas, the woes of using open source software rear their heads. WordPress abounds with undocumented, or at least very poorly documented, features.

My dilemma: the default function for displaying a list of page links (used on this site to populate the Points of Interest panel in the sidebar) sorts links alphabetically, and there isn’t any obvious way to make it sort by the database’s menu_order field, which logically, to me at least, should be the default especially given that this is how they’re sorted in the admin tool.

Finding little help in the documentation or by my usual means (Google), I decided it couldn’t be done without modification. In my previous installation of WordPress I actually modified the core code itself to change the sort order, but when I upgraded to version 2.1.1 today, it overwrote that change. This time I decided to try the plug-in approach, so my changes would actually stick through version changes, and so I could get familiar with the powerful but arcane plug-in system WordPress uses for extensibility.

After poking around futilely trying to get my plug-in to work (to the point where it was sorting all of my blog posts the way I wanted the pages to be, but not the page list), I stumbled upon a relevant post in the WordPress forums, where a snide jab at “theme designers” (which seemed to be such a broad swipe that it included me) happened to mention an input parameter in the function that calls the page list!

Silly me… the system has built right in a very simple way to sort the list by whatever field you want, and all you have to do is pass in the right parameters in your theme files. The change couldn’t have been simpler… but learning that it was possible certainly could have!

A fix for a fix in WordPress 2.1

One thing that surprised me when I started using WordPress again is that its search function only searches on blog posts, not on static pages. I suppose if most WordPress sites are 99.9% blog posts, then it probably makes sense, but I have enough static pages on my site that I’d like to make searchable to warrant changing this.

Fortunately, someone has. Unfortunately this “Search Pages” plug-in is out of date and no longer works with current versions of WordPress. I dug in a bit and figured out why: the plug-in alters the SQL query that performs the search, but the substring it replaces in the query no longer exists! So I hunted down the place where the query occurs in the WordPress core, adjusted the plug-in as needed, and it works!

Here, then, is my hack of the Search Pages plug-in, modified to work with WordPress 2.1. (I’m not sure which other versions of WordPress it will or will not work with.)

[ search_pages.php.tar.gz ] [ search_pages.php.zip ]

Thanks, Bill… this is just how I wanted to spend my Saturday

Bill, I really don’t have time for this.

Internet Explorer 6 is incapable of properly rendering CSS applied to a <div> tag when the only child element in the <div> is a table. It sticks arbitrary margins in the document below the table. Here’s an example from a site I’m working on (colors removed to [sort of] protect anonymity). This is how it should look, as rendered by Safari:

Safari screenshot

The concern is the content in the dark title bar. The bar itself is a <div> and the two buttons plus the month/year text is contained in a table. Here’s how it looks in Internet Explorer 6 (note the gap below the header bar):

Internet Explorer screenshot 1

OK. So let’s see, maybe there’s a semi-logical CSS workaround. I already have margin: 0 defined for the class the <div> uses. So I added it to any tables contained within that class as well. No luck. Then I did something really off the wall and added a display: inline property for tables contained in that class. It still didn’t work. So then, appropos of nothing, I added a &nbsp; just so there would be something in the <div> besides the table. And here’s the kicker… I actually added it before the table (retaining the display: inline property of the table:

Internet Explorer screenshot 2

Once again, it’s good that the windows in my office don’t open, or there would be one less PC in this building right now.

Of course the &nbsp; solution is not satisfactory to me. The search goes on. Because, you know Bill, I really have nothing better to do when I’m working on a Saturday morning.

At this point another alternative occurs to me: it’s possible to use the CSS float property to position the buttons and eliminate the table altogether. That fixes the problem in Internet Explorer, but…

Steve, I’ve got a few words for you as well! Look what happens in Safari when I remove the table in the header:

Safari Screenshot 2

Sure, that makes perfect sense. Especially since I have a width="100%" attribute right there in the calendar table. Oh, and did I mention that the width of the panel body is explicitly defined in pixels in the CSS? How is it, how can it be possible, that removing a table from a separate (albeit adjacent) <div> could affect the width of this table?

Now where’s my glass cutter? I think there are one too many PCs and one too many Macs in this office.

After a bit more head scratching, I’ve discovered that the cause of the Safari issue is that I neglected to remove the aforementioned display: inline property I added to my CSS in the midst of the numerous futile experiments I undertook to resolve the initial IE problem. Steve, you’re off the hook.

So, in the end, it turns out that the solution to my problem is to abandon the old-school table-based method of layout and go strictly CSS. I’m sure that’s precisely what Bill wants me to do.

Now this is funny!

According to this article, the first security exploit has been found in Windows Vista.

While that’s not entirely surprising in itself (after all, the OS has been commercially available for over 3 full days now), the nature of the flaw is both amusing and somewhat shocking.

Vista adds new speech recognition features, allowing the user to issue commands to the computer by speaking. At least, I’m assuming this is new. Mac OS has had speech recognition for at least a decade, but it used to require extensively “training” the computer to recognize your voice. I’m guessing that the new speech recognition software doesn’t require that kind of training, sort of like how pizza places now have speech recognition software that answers the phone and takes your order.

So, on to the exploit: if speech recognition is on, and the computer’s speakers and microphone are both on, it would then be possible to visit a website that autoplays an MP3 of a voice issuing commands to make the computer do all sorts of nasty things (like erasing files off the hard drive)!