Web Design and Build

Body classes on WordPress pages Last updated:11 November 2010

I spent hours this weekend trying to apply a different body class to a WordPress page. Specifically, I wanted to apply a different class to WordPress pages as opposed to WordPress posts. Why? Because I wanted to be allow comments to be left on a number of pages which were previously outside WordPress, but I wanted the menu, in line with the rest of my site, to display the submenu for either web pages or photo pages, depending on the actual page displayed. My css controls this by using the body class.

Once I’d worked it out it was straightforward, inevitably. First off, I used the “Custom Fields” functionality to define a custom field called bodyclass, then set this to “web” or “photo” as my css requires. Easy so far.

I then amended header.php using WordPress conditional comments to use the bodyclass value for pages, and to use “blog” as standard for posts. The following statement did the trick here:

<body class="
<?php if (is_page()) echo get_post_meta($post->ID, 'bodyclass', true); 
else echo "blog";?>
">

jQuery fadeIn and fadeOut problems with IE8 Last updated:29 October 2010

I’ve just written a jQuery plugin to allow a user to simply configure some dropdown menu animations. It tests fine in IE6 and IE7, but the fadeIn/fadeOut didn’t work in IE8. Unbelievable. It astonishes me the things that fail in IE8 but were fine in IE7.

The specific instance here was fading a drop down ul element, which was positioned absolutely with respect to an li element with position:relative. You know, standard stuff. Turns out IE8, position:relative and fade don’t play nicely. The solution in the end turned out to be applying:

filter:inherit

to the li element. Applying this to the ul has no effect. This doesn’t seem to cause any issues with IE6 or IE7, fortunately.

I also found that in IE8 as the fadeIn completes, the faded text appears to jump a pixel to the left. This isn’t tragic, but it’s a bit irritating. I found that this only happened if I used the fadeIn method. If I fade in by using .animate() to change the opacity, then the jump goes away.

You can see the final result here if you’re interested.

Experiments with @font-face Last updated:29 October 2010

I’ve previously been a fan of Cufon for rendering web fonts, but this morning I thought I’d have a play around with @font-face. I tried it, of course, in Firefox first, and it worked. Hurrah. But IE uses its own proprietary font format .eot, created, or so I thought, by Microsoft’s own product WEFT. I’d heard the WEFT tool was unpleasant to use, but this still hadn’t prepared me for the grim reality….

However, via this excellent article I found Font Squirrel which does all the work for you.

Internet Explorer continues to be a pain, however, and applying the necessary css for IE needs some novel css construction – see the article for details. Having overcome this…

…you should see this text in a NASA-like font…

…unless you’re viewing in Opera 9, which doesn’t support @font-face. Otherwise, nice.

EDIT THE NEXT MORNING: After further experimentation I’m slightly put off by the “flash of unstyled text” which is noticeable in Firefox at least. There are some javascript hacks to try and address this, but if I’ve got to use javascript I think I’ll stick to Cufon for now.

Problems with From and BCC headers in PHP mail() Last updated:29 October 2010

Had a funny one this week. My wife discovered that nobody on her mailing list had received any emails since we swapped hosting packages back in May. Before the swap things were fine in a Windows server, now clearly not fine on Linux. On further investigation, I spotted that the From: and Bcc: headers weren’t being split out properly, and hence we were getting the Bcc was included in the From: field like this:

From:mail@mydomain.com Bcc: mail1@test.com, mail2@test.com etc etc

This was my original code:

$headers  = 'MIME-Version: 1.0' . "\n";
$headers .= "Content-type: text/html; charset=utf-8" . "\n";
$headers .= "From: Sender <sender@mydomain.co.uk>"."\n ";
$headers .= "Bcc:".$bcc."\n";

mail($to, $subject, $message,$headers)

Same result replacing \n with \r\n. No joy even on Coding Forums, but after a lot of Googling I found the solution, which was to replace the newline characters with the PHP constant PHP_EOL:

$headers  = 'MIME-Version: 1.0' . PHP_EOL;
$headers .= 'Content-type: text/html; charset=utf-8' . PHP_EOL;
$headers .= "From: Sender <sender@mydomain.co.uk>".PHP_EOL;
$headers .= "Bcc:".$bcc.PHP_EOL;

mail($to, $subject, $message,$headers)

Glad to say this did the trick. PHP version 5.2.13 if anyone’s interested.

Cross-browser consistency Last updated:29 October 2010

Once upon a time there was a business that wanted a very simple website. So I built one as a small project. It had a few pictures and some text. I looked at it in IE7 and it looked OK. It was a first step into the web world for the business. The client was happy.

A year passed. The website started looking a bit tired. It needed some more pictures. So I rebuilt it, added more pages and a lot more pictures. I looked at it in IE7. It looked OK. I looked at it in Firefox as well. It looked OK. It didn’t look quite the same as it did in IE7. I found that if I used tables in the design, some (but not all) of the differences between IE7 and Firefox 3 went away. (Don’t start shouting until you’ve read the rest of this page….) I decided I could live with the differences. I didn’t understand why Firefox was getting it wrong though. The new website went live about 2 months ago. The client was happy. So were his customers.

For other purposes, for another website, I’d been learning a bit about “Cascading Style Sheets” – css to the initiated.

I happened to show the website to someone I was working with. Having previously been quite proud of it, I was a bit embarrassed – the site navigation looked a bit naff. So I made the navigation look like buttons. It was quite easy to do this using the css I’d learnt. So I extracted all the style into a separate css file. The page looked quite a bit better with the buttons. The client was happy. It still didn’t look quite the same in IE7 as it did in Firefox 3. I decided I couldn’t live with this any longer. I spent hours trying to understand this. As a result of this I learnt a lot about css. Every time I looked at the html or css I spotted something that could be done better, so I changed it. This became a fascinating journey into the world of modern web applications, or as my wife called it, an obsession. Where I could get it to work, I got rid of the tables I’d used. I got rid of some of the differences between IE7 and Firefox. I started to realise it was IE7 that was doing the unexpected things, not Firefox. I started viewing what I built in Firefox first not IE7 first.

I made the mistake of posting a question on a discussion board. In line with all website discussion boards everywhere, I didn’t quite get the answer to the question I asked, but I did get some comments about how the website was built, using lots of absolute positioning. I rebuilt the website using some suggested code off the discussion board to use floats and margins instead. It still looked pretty much the same to the untrained eye…..(not someone comparing using a pixel ruler).

Getting curious, I had a look at the website in Chrome as well. It looked the same as in Firefox. Hurrah. Then I looked in Opera. Boo.  All the text was cut off on the right (EDIT: which I now realise was this problem, and nothing to do with margins at all). I took all the floats and margins back out. It looked OK in Opera then. I went to bed…..

In the morning I started again. I got rid of all the absolute positioning again. I did it in a slightly different way and it seemed a lot easier. I got rid of an extra line showing up in IE that was at the top of every page. The Home page looked identical in IE7, Firefox, Chrome and Opera. It was wrong in IE6 however. I fixed that. Now it looked the same in all of them. I centred the page and put a nice swirly background on. I looked through all the rest of the site. I noticed that the spacing around the horizontal lines was different in IE than all the rest. I fixed that as well. To do this I had to write a “hack” in the css so that IE would read one bit of css and everything else would read the rest.

Then I had a look at the page in IE5.5. Why? Because from the logs I could see one user using IE5.5. This turned out to be the client….. What a mess in IE5.5. Font sizes all too big. Like being shouted at. I found another hack that fixed this.

Finally, had a look at the site through Safari. And it looked…….fine! So, the site looked the same in all the likely browsers, and the unlikely ones as well. (I know, I haven’t tried IE8 yet.)

OK, here’s the moral of this story. The client likes the new swirly borders, although he won’t see them using IE5.5 and a screen resolution of 800 by 600. Otherwise the site looks pretty much the same as it did 2 months ago despite being completely rewritten. Nobody but me has looked at the site in Chrome or Opera. It’s probably still got some issues I haven’t understood yet. I know a LOT more about css and html. The web pages have still got some tables on them, which are debatably holding tabular data.

The client is still happy…

If you’re looking for some hints and tips on browser consistency then I’ve pulled together some more details on this page.