UNDERDOG of PERFECTION

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 ]

I’ve continued to tweak the two tracks I’ve been working on for the new album. I just posted a major update to “Heavy Water,” which you can listen to here or on the “official” page for the album.

I also posted minor updates to both tracks yesterday, in place of the earlier versions that were there. I didn’t bother to draw attention to them though, as they were basically just tweaks to the masters.

In addition to the current projects, I have a 16:18 ambient track I recorded last year, called “1.618” (because it’s based on the golden ratio… the length of the track is a deliberate play on that number), that I’m planning to add as the final track on the CD. It needs some clean up back over in Pro Tools (because I discovered GarageBand buckles under the stress of loading a pair of 16-minute waveform tracks) and a new master. I got a new computer since I worked on it, and all I seem to have backed up are the Pro Tools project and an MP3, but no CD-quality mixdown. More on that later.

Note: To conserve server space, I’m clearing out older versions of the Hors d’Oeuvreture songs. Visit the album page to hear the latest available version of each track!

I’m fascinated by this. Apparently these skeletons have been unearthed in Italy during excavation for a new construction project. There’s just something incredibly compelling about this photo.

The first couple of tracks for my new CD, tentatively titled Hors d’Oeuvreture (and tentatively featuring the wonderful Photo Booth-generated photo of yours truly, shown at right, as cover art), are now posted for your listening (dis)pleasure. Check them out now!

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:

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):

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   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:

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   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:

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.