darkryder

Thank you so much! Not only is this a handy trick, but in the process of taking my three files (functions.inc.php, defaults.inc.php, and options.inc.php) and turning them into a single file, I found the source of the problem.

You know what makes your include()ed files work better? Putting <?php at the beginning…

>_<

It looks like you’re running into two different bugs in IE. First, IE6 and earlier don’t support PNG images with alpha layers (your backgrounds look fine in IE7). There’s a workaround, but AFAIK it can’t be applied to background images. Alternatively, some image editors (I know that Paint Shop Pro does and I imagine that Photoshop does as well) allow you to specify the “background” color of a PNG. This color gets ignored on viewers which support the alpha channel, but will get used by IE. If you set this to the median color of your background (looks like #2B2B2B), then it will at least look less ugly (the color will be mostly right, but the edges will still be slightly visible).

The other problem is that IE6 and IE7 use the wrong box model by default (IE5.5 and earlier always use the wrong box model). You can fix this easily enough in IE6 and IE7 by triggering Standards mode, but the margins will still be off in IE5.5 and earlier. The alternative is to use conditional comments to include a special, IE-only stylesheet which includes margins more to its liking (use “[if IE]”). You can also combine the methods by triggering standards mode and including a conditional stylesheet which triggers on “[if lt IE 6]”.

HTH!

Sorry, I guess I’m habitually forward-looking when it comes to writing code. ^_^

In general, I’d prefer to avoid editing the core WP files — as long as my template is completely self-contained, not only is it suitable for use by others, but I can also upgrade WP in the future without having to worry (as much) about code changes. I’ll just borrow the SQL from list_cats and write a function which caches and returns the record list. That way, I can do whatever I like with those categories without having to rewrite the SQL every time I change my mind.

Thanks for the advice, though!

Oh, it wouldn’t be difficult, I just read somewhere in the plugin docs that you aren’t “supposed” to write functions which touch the database. I guess I’ll probably end up doing it anyway.

It seems like it wouldn’t be a bad idea to separate out the database code from list_cats and dropdown_cats, anyway. As it stands, if someone calls both functions in the same page (not all that unreasonable, depending on the design), it results in separate database queries for the same data. If the database code were moved to a separate function, say get_cats, the results of the first call could be cached and made available to subsequent calls without additional database queries.