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!

Forget what I said before; we have a winner!

It’s a given that anything I post here is going to be brain-deflatingly stupid. But this one goes beyond even what I would have expected of Microsoft. Fortunately, thanks to a highly effective Google search, I was able to solve the problem in minutes.

The problem was this: For a site I’m working on, we are manipulating the 404 error feature to allow users to set up customized URLs. If the URL entered doesn’t match a real page, it gets fed into this 404 error script, which looks up the path in a database and redirects the user to their customized page. A bit of a hack, but it’s pretty slick.

As usual, I am developing the site using Firefox as my test browser. But… UH-OH! Surprise! When giving a demo of this feature today using Internet Explorer, we discovered it didn’t work! Internet Explorer was not returning the server’s 404 error page, instead using its own internal version (which we’ve all seen and most generally ignore).

Drat! What to do? Well, as it turns out (thanks to the aforementioned Google search), the problem is quite simple. To quote the unbelievable but, as I verified, 100% accurate description I found on this page:

Internet Explorer has a lightly-documented “feature” that stops it from serving any custom 404 error page that is less than 512 bytes long. Your visitors will instead be sent to IE’s own 404 page, which is generic and suggests they use an MSN search to “look for information on the Internet.” That’s one way to lose visitors! Make sure your custom 404 error page is over this limit — about 10 full lines of text and HTML should be enough.

Yep, that’s it. I did my best Bart Simpson-at-the-blackboard impersonation, filling my 404.html file with a large comment block wherein I repeated (about 130 times, for good measure) the phrase “This block exists solely to force Internet Explorer to load this page.”

Sure enough, it worked. D’oh!

Thinking a bit more about this, I at least think I understand why Microsoft chose to do this. “If the server’s default 404 error page is so short,” I imagine them musing, “then it probably doesn’t offer users much helpful information. And since our wonderful web browser is much more important to our users than the web pages themselves, let’s just butt in and do things our way. (Is there really any other way anyway?)”

It’s not finished yet, but it’s already pretty stupid…

You may or may not have seen my Stupid JavaScript Tricks A–Z page. For a while I’ve had a mildly enticing teaser on that page promising “something big” when I get to the letter D. Well, I finally decided to skip C and get started on that “big” letter D. It’s about half done, but since I only get the inspiration (and time) for these kinds of things in short, sporadic bursts, I decided to run with it and post it in a half-completed state. The real topper is what comes next, and hopefully someday I’ll get around to it.

In the meantime, please check out the incomplete… Delete the Internet.

Microsoft, how do I hate thee? Let me count the ways…

Most people who know me well understand that I am an acknowledged Apple fanboy. But I don’t simply hate Microsoft because I love Apple. There may be more truth to the fact that I love Apple because I hate Microsoft.*

At any rate, it’s clear that I hate Microsoft, and for reasons that are much more concrete, tangible, and, in the context of this article, quantifiable.

As you may know (if you know me, and probably wouldn’t if you don’t, but you do now… get it?), I make my living building websites, which means that I am forced to deal with both Windows and Internet Explorer, like it or not. (Not.) I do my work on Macs, and my day-to-day web browser is Firefox. But everything I do needs to be tested in the Microsoft world, since that’s the context in which 95% of my audience will be viewing my work.

At least once every month or two, I am forced to bring my work to a grinding halt while I attempt to diagnose some obscure Internet Explorer problem I’ve just run into. It is usually some trivial function that I take for granted, but for some mysterious reason simply does not work in Internet Explorer under a particular set of conditions. So I spend a day or so fruitlessly searching Google to find others who’ve experienced the same problem. Eventually I resign myself to the fact that there is no logical explanation for the problem and I will never discover a real solution to it. So, the only alternative is to concoct a hokey workaround that Internet Explorer can accept. These weak victories are always bittersweet: at least I’ve found a way to move on and get back to the real tasks at hand, but my work is forever tainted by Microsoft lameness, without even giving me the satisfaction of a glimmer of understanding as to why I’ve just undergone a day of torture.

Finally, I’ve had enough. I know that as long as I work in this field, I will always have to deal with this problem, but I’m no longer going to silently submit to the whims of mediocre software. I will catalog my woes here for the world to see, so when I finally jump off a bridge with a thousand Windows Vista CD-ROMs tied around my waist, people won’t wonder why.

* For the record, I don’t unequivocally hate everything Microsoft does. I own, and enjoy immensely, an XBOX game console.

The mysterious window.print() problem

It seems an easy task: print the damn window. But no, nothing is ever as easy as it seems with Microsoft. In this particular case, I have a pop-up window which contains a frameset. The frameset consists of a left frame with a tree of page links, and a right frame containing the body of the page linked from the left frame. Within the body of the page in the right frame there are links to allow you to print the frame. So far, so good. But there’s also a special link that opens a new page that contains the full content of all of the pages, so you can basically print the whole lot at once instead of one page at a time.

As expected, all of this works just fine in other browsers, but not in Internet Explorer. It handles the regular single-page window.print() just fine, but when you go to the full page, nothing. No printing, no JavaScript errors, nothing. It’s like it’s just a dead link. With the exact same code as what works on the other pages. And, if you open the page from the frame in a new window by itself, it prints just fine. So, we have some pages printing just fine in the frame, and another page that prints just fine when it’s by itself, but it won’t print if it’s in the same frame that the other pages print fine in, using the same code. You can see why this is driving me insane, can’t you?

Nothing I find anywhere online suggests that this problem exists. So eventually I resort to the only option that’s available… open the troublesome page in its own pop-up (yes, a pop-up opening a pop-up… always a great idea), where window.print() works just fine.

Thanks again, Microsoft!