Ethan Codes

Recently my brother got a SPOT emergency beacon. One of the features is a non-emergency “check in” feature. He hits a button and it logs his location. Turns out, that log has an RSS feed. So I built an application to take the feed and put the items in a database. Then I build a page with a Google Map. The map pulls coordinates from the database and puts little markers on the map. Each marker is clickable, and a little balloon pops up that says “At such and such a date and time, I was at some address.” The markers are connected chronologically by lines. The most recent marker is a different color, and the map centers on that location.

I want to say a little something about hardcoding values. Don’t.

Here is my example. You have an online application. It has 13 pages. You have a pointed that says what page the user is on. When that pointer gets to 14 it means the user is done and they get a summary page. That’s okay. But then you put something like this throughout the code

if ($ap['pointer'] == 14) { ... }

That may make sense to you in the short run, but eventually it’s going to bite you (or more likely, whatever poor sucker inherits your code) in the ass. What happens when we add/remove a page? I have to go change all of those 14s to something else. Where are all the 14s? How long is it going to take to fix all the values you’ve hardcoded?

I seem to train a lot of our clients in Wordpress, so I thought I’d write something up. Copy/Pasted here, for your entertainment.

In my experience, most people think Wordpress training is going to be terribly complicated. Usually, they don’t “get” computers and don’t expect to understand a content management system, either. Once they see how simple Wordpress is, they can usually take care of their content on their own.

I usually start by explaining that they don’t need to worry about copying down any URLs, usernames, or passwords because I’ll send those by email. This is one of those things that stress people out, so already they don’t have to worry about something.

I explain a little bit about the Dashboard. Usually by this time I have cut out most of what shows up on the Dashboard in order to make their lives easier. Nobody cares about the Wordpress Development Blog, so turn that off before-hand. The Dashboard is nice because there’s multiple ways to get at what you’re trying to get at.

Then I explain that there are two kinds of content: Posts and Pages. I explain what they are. The concepts are pretty simple.

Then I show them Posts. Once they see that it’s just a Title, Body, and a Category, you can watch them relax. This isn’t so hard. The editor is friendly and easy to use. Inserting an image is easy. Uploading a PDF is easy. Links? No sweat. They can do this. I usually ignore everything else on the Post form page because it doesn’t matter to them.

I usually go through the process of editing existing Posts, and then creating new Posts. I show off how creating a Post in the News category automatically shows up on the News page, and the Home page. That sort of thing. People are relieved by automation.

When people see that a Career Opportunity is just a Post in a different category, they see how simple it is.

Ask if there are any questions or if anyone would like to see something again. Take a drink of water.

Then I go through Pages. They like that pages are organized hierarchically. And Pages have fewer fields than Posts, so they can handle this, too.

People are often very concerned about screwing something up. I mention the Preview button. I tell them they can check the front end after they’ve made changes, and if anything is wrong, go back and edit it. And I mention the revisions. Nobody has ever needed the revisions.

Any questions?

That’s usually it. The thing I hear almost everyone say is “that’s really simple” and “I’ll have to get in there and play around.” Even after seeing how easy it is, people think it’s voodoo. But nobody really has any trouble with it once they’ve tried it themselves.

I spent an hour trying to get the jQuery UI accordion to work and it just wasn’t right. So I wrote my own. And then, the next day, I made it simpler.

Get the files here.

Assumes you are familiar with jQuery and Highslide…

// prep "a img" for highslide
$('a').each(function() {
  if ($(this).children('img').length > 0) {
    $(this).addClass('highslide');
    this.onclick = function() {	return hs.expand(this); }
  }
});

Building on ideas I posted earlier, I’ve come up with a clever way to allow users to manage the images that appear in a rotating-image-block.

Upload the images into a page. I called my page “Rotating Images for the Home Page.” Then, in your template, fetch the contents of that page and format them for display. Once your HTML is set up, your rotating image script can take over.

Remember to hide your page from navs. I’ve started putting all my “special” pages under a page called “Special Pages Not In Menus.” That way, all I have to do is exclude the top-most special page once, and any special pages under it are hidden from the menus as well.

A popular home page design is a sort of newspaper layout, with lots of little blocks of content. An example of that is this website we did for Gilda’s Club.

What we want to do is make the “Mission” block, in the middle right, editable through Wordpress. It’s actually pretty easy to do.

1. Create a new page. Call it something like Home Page: Mission. Copy/Paste the content in there.

2. If you have the kind of navigation that picks up pages automatically, you’re going to need to add the page id to an exclude list in your wp_list_pages() call. This may be the header navigation, sidebar, and/or footer.

3. Now we’re going to modify our template. Find the part where that block content is hardcoded into the template. Replace it with this:

  $page_id = 541; // change to your page id, obviously
  $post = get_page($page_id);
  setup_postdata($post);
  the_content();

And you’re done.

The last few days I’ve been playing with Google’s Chart API. It’s much simpler than their other APIs. This is pretty close to dirt simple. My only “complaint” is that a lot of the variable names are a bit obscure. I’m unlikely to remember that chxl means chart axis labels. So I started writing a little class to help.

$chart = new googleChart($data, $title, $width, $height)
data should be an associative array
- your keys become the x axis
- your values become the y axis
title, width, and height are optional

$chart->title = ‘This is my title!’;
$chart->width = 400;
$chart->height = 400;

color is the color of the line
it must be a hex code
$chart->color = ‘ff8800′;

fill is the color of the space under the line
it must be a hex code
$chart->fill = ‘ffff80′;

then all you have to do is call
$url = $chart->getURL();

You can check out my “alpha release” here.

One of the cool new things about wp2.9 is support for post thumbnails. What this means is that you can associate an image with a post, as a thumbnail for that post.

Previously I have had to write all kinds of code to pull the first image embedded in the body of the post, resize it, and throw that into the template. For example, a “Current Projects” page. Each project on this page is a Post in the “Current Project” category. You can embed/upload an image into the body. My template then extracts the image from the body, resizes it, makes a link out of it, and displays it on the page that lists all of the Current Project Posts. I’ve done this so many times I copy/paste the code from one project to another.

WP2.9 has this post thumbnail business. Which is brilliant. You enable support for post thumbnails in your theme. Then there’s a new block on the Post edit screen where you pick an image to use as a thumbnail. You don’t upload it to the body, it’s separate and clear. Then I use two functions in my template code to check whether or not there’s a thumbnail for this post, and if so, output it.

Dirt simple. I love it. I played around with this a bit so I know how it works. I can’t wait to put it into practice.

Nobody likes to do browser testing. Nobody wants to do it. It’s like cleaning your room. You keep hoping that if you put it off long enough it will go away. So the first thing to understand is that browser testing MUST be done. Suck it up.

That said, there are things you can do to minimize the amount of browser testing you have to do. If you understand the kinds of things different browsers tend to do differently, you can build your HTML and CSS accordingly. For example, if you float something to the right but do not give it a width, IE6 will probably mess it up. If you know that ahead of time, you can put widths in your floated containers when you build it and save yourself some headaches later on.

Of course, eventually you’re going to have to just do it. When you get there, I think it’s best to take a “shortest route possible” attitude. Do the simplest thing possible to make it work. Don’t rethink your whole HTML structure unless you absolutely have to. This means you may do some things that are less than perfect, but when it comes to browser testing all that really matters is that it looks good on the front end. Whatever the quickest way is, just do that.

If you were the kind of kid who didn’t need to be told to clean up your room, maybe you’re the kind of developer who browser tests as soon as possible, and repeatedly. The sooner your get the browser testing over with, the better. But also, you will probably keep tweaking the design until the site goes live. It’s not a bad idea to do multiple waves of browser testing.

Stylesheets. This isn’t Highlander, there can be more than one. Include your “core” stylesheet first. This is where the majority of your CSS goes. The website should pass browser testing almost entirely with just this “core” stylesheet. Only create other stylesheets to fix small things, and include them after your “core” stylesheet. Name them something clear, like styleIE7.css. It’s up to you how you include them. I am fond of using a PHP function to determine browser info, and then spitting out an HTML link tag for the appropriate stylesheet. Like I said, try to fix as much as you can in the “core” stylesheet and keep your browser specific stylesheets to a minimum. I have stylesheets for IE7 that have only two definitions. Clean and simple.

I want to take this opportunity to ask you to comment /* the crap out of */ your stylesheets. Organize them, so that all of the #header stuff is together with a comment explaining that this is header stuff; all of the #nav stuff is together with a comment denoting the start of navigation stuff; all of the #footer stuff is together; and so on. Keep it neat and tidy. Ship shape. This makes it easy for you (and your team mates) to find things. It’s less confusing when trying to debug an issue. The only thing worse than browser testing is browser testing someone else’s design, so when you’re building your stylesheets remember that someone ELSE may have to browser test it.

Lastly, decide, with your team, what browsers you are going to support. This should be agreed upon and known. Consult some browser usage statistics when making this decision.