This is not a new trick, and I certainly did not invent it. It’s been used before, but when I went searching for information about how to do it, it was hard to find. In fact, I finally had to ask a friend who is much better at PHP than I am to help me (I only recently learned to spell P-H-P). This is really basic stuff, but for a lot of us, basic is what we need to get on with our projects.

Sometimes, you need things to NOT appear on a page unless something else that goes with it appears on the page. This is a pretty basic capability for most CMS systems, but I had never done it with WordPress on a page-by-page basis.

Here’s the scenario. I wanted to add a highlighted note in the subnavigation area of my WordPress theme, Evo4 CMS, and I wanted it to be tied to the content of the page it appeared on. I hadn’t used custom fields much, but it seemed to me that was the way to go. Here is an example of the code I wanted to appear below the subnavigation items on the pages:

<div class="sub-note">

<h5>Subnav Note Heading</h5>

<p>Sed do eiusmod tempor incididunt velit esse cillum dolore duis aute irure dolor.</p>

</div>

Pretty simple, right? I decided that, for greater flexibility, my client would have to be responsible for the HTML formatting within the div (this particular client is capable), but I did not want them to be responsible for the div itself, as things can get ugly when someone forgets to close a div or attaches the wrong class to it. In the WordPress backend, on the page on which I wanted the note to appear, I created a custom field named "subnavnote" and added the value (same as above, but without the div):

<h5>Subnav Note Heading</h5>

<p>Sed do eiusmod tempor incididunt velit esse cillum dolore duis aute irure dolor.</p>

On the page template in my theme (page.php), in the subnavigation column, I added the following:

<div class="sub-note">

<?php echo get_post_meta($post->'ID, 'subnavnote', true); ?>

</div>

Woohoo! That displayed the text from the custom field in the subnavigation area. But there was a problem: when I went to other pages, an empty "sub-note" div displayed (CSS specified padding and a background color for the div, which caused it to be visible even when empty). And that was definitely NOT something to yell "woohoo" about.

I needed a way to make the div appear on a page only if there was a value for "subnavnote." No note, no need for the note container. This was where Googling left me high and dry, as I didn’t know the right terms to use, or how to ask the question so that I was able to find a usable answer. I have no doubt the answer was and is out there, but it remained outside my grasp.

After fiddling and failing with some PHP code snippets, I asked a friend who is a PHP coder for help. Here’s the solution she gave me:

<?php $subnavnote_value = get_post_meta($post->ID, 'subnavnote', true); ?>

<?php echo ($subnavnote_value != '') ? "<div class='sub-note'>".$subnavnote_value."</div>" : ''; ?>

Basically, if there is no value for the custom field on a particular page, this code prevents the div that contains the custom field content from appearing. And if there is a value for the custom field, both the value and its container div appear on the page.

I would break down the code and explain it if I was competent to do so, but I’m not (P… uhh… H… um…). I can see how it works, however, and have adapted it to other similar circumstances, which greatly increases my ability to use custom fields. I hope this solution is similarly useful for you.

Tags: Custom Fields, PHP for Designers, WordPress, WordPress as CMS

One of the best things you can do to set the tone of a blog post and encourage people to read beyond the heading is to include an image. Most bloggers understand this, because an awful lot of them use images in their posts. But "misuse" of images is more common than "use" of images, if you have the perspective that the purpose of an image in a blog post is to communicate.

Here, then, are 6 rules (I could have called them guidelines, but then no one would argue with me) for using images in your blog posts which deserve a yellow flag when violated:

1. One image per post.

Blog posts are usually short; 300-800 words is a commonly suggested length. That small amount of text simply does not create enough screen real estate to accommodate several images without looking cluttered and unreadable (you DID want people to read your post, right?). The idea of "less is more" has never been more applicable. In cases where multiple images are truly called for (e.g., you have a series of photos showing attendees at an event), you can use one anchor image with a link to launch a Thickbox slideshow (or similar). This is also a good technique to use when you need a large image to show critical detail.

2. Put the image at the top of the post.

Put the image where visitors can see it immediately, right below the heading of your post. I personally like to align the image to the right at the top of the first paragraph: the image is where they can see it and connect it to the heading, but it doesn’t block their entry into the post text as it might if it were aligned left.

3. Make sure the image relates to the heading of the post.

An image should not leave your readers wondering what the connection is with the post, either before or after (or if) they read it. The image should immediately and clearly support or illustrate an idea in your post heading. Most people view disconnects and non sequiturs as annoying, rather than intriguing. If you can’t find an image to relate to your heading, consider changing your heading.

4. When looking for images, bring along your sense of humor.

A little humor or irony in an image (as long as it’s obvious: reread no. 3) can draw people into the post. It’s a bit like telling a little joke before a speech. Of course, if the "joke" is inappropriate or misleading, then you’ve created another issue. So don’t do that.

5. Crop and size images appropriately before uploading.

Any time you see an image that seems to take forever to load in a post, chances are you’re looking at a big image that has been scaled to fit, rather than sized to fit (i.e., the blogger uploaded a 1200-pixel-wide image and scaled it down to 220 pixels wide in the blog editor, instead of resizing the image to 220 pixels before uploading). Get an image editor and learn to use it to crop and size images, at minimum.

6. Don’t use clipart or stock photos. Unless they’re pretty good.

A lot of clip art and stock photography is trite and awful and over-used. But some of it is clever and very good and it perfectly illustrates your concept. Put your photo-editor hat on and refuse to use the former. Under no circumstances should you use an image of a multi-ethnic and gender-balanced group of young people with perfect teeth dressed in business casual gaping in awe at the screen of an open laptop in a brightly-lit conference room.

Tags: Communication, Design/Development

Although I design and develop on a Mac Powerbook, I mostly ignore Safari for two reasons:

1. Safari is about as standards compliant as browsers get, so it rarely needs any special attention.
2. Safari is used on fewer than 4% of all computers (and it seems to have peaked).

I use Firefox almost exclusively (although I’m now experimenting with Chrome for Mac), because it’s very standards compliant, and it gives me about 99% of the same results as a PC version of Firefox. Using FF in my development process means I have the biggest browser covered (that’s right, FF has over 46% of the market, with IE6-IE8 combining for just over 37%). I use crossbrowsertesting.com to hunt for problems in IE. Ideally, I want my work to look the same in all browsers (but I’ll settle for “close” in IE6).

That said, I try to keep in mind an old saying in the web design business: The most important browser to develop for is the browser on your client’s screen. One of my clients is an ad agency, and they are completely tied to Safari (I’m pretty sure they’ve heard of Firefox, but…). So, looking good in Safari is a priority on their projects. Rarely is there a need for a hack, but occasionally it happens.

There seems to be only one reliable CSS-only way to target Safari (incidentally, it also targets Chrome, which has almost 3x as many users), outlined way back in 2007 by Dustin Brewer. You can put this in your style sheet to enclose Safari-targeted rules:

@media screen and (-webkit-min-device-pixel-ratio:0) {
/* Safari 3.0 and Chrome rules here */
}

But then you have a hack in your style sheet. I find it’s easier to maintain (and find) hacks by putting them into a different file, and your basic style sheet is more likely to validate. I experimented with using the above selector in the header to point to a different stylesheet, but had some issues (don’t remember now what they were). Finally, I settled on putting the following in the header, following the basic style sheet link:

<style type="text/css" media="@media screen and (-webkit-min-device-pixel-ratio:0)">
<!––
<?php include("includes/safariCSS.php"); ?>
––>
</style>

This displays the contents of an include file, displaying CSS rules in the header as an "internal style sheet." The contents of the php include file consists of CSS rules, but is not a CSS document. Internal style sheets in the header are usually to be avoided due to maintenance and consistency issues, but by using an include, the Safari CSS for all pages is editable in one file.

By the way, the CSS rules from the include appear in the header for all browsers, but the “@media…” statement means all but Safari and Chrome ignore the styles. Given that I’ve done websites with some extremely complex CSS and only needed 2-3 rules targeting Safari, I don’t think this approach risks adding much overhead.

View a Demo | Download Demo Files

Server Side Scripting Reminder: Because the include is PHP, which renders on the server, the files will not work locally on your computer. To see the results of your experiments, upload the files to a server that supports PHP.

Tags: CSS, Design/Development, PHP for Designers