Simple excerpts in WordPress

I have finally decided to plunge into some PHP code in my WordPress template. The reason? My home page is a little long. So are my archive and category pages. I write moderately lengthy posts, so even with 5 posts per page, you might have to scroll a bit.

First, I want to say that I have never learnt PHP. I’m also unfamiliar with the innards of WordPress. But I’m a programmer. The code doesn’t look too hard… so I’m still capable of making small changes.

I’ve heard about the use of excerpts, and because I’m too lazy to set them up properly with the more tag, I’m doing it the simple way. This is the code I used:

<?php if(is_category() || is_archive() || ($postcounter!=1 && !is_single() && !is_page())) {
	the_excerpt();
} else {
	the_content(__('Read more &raquo;'));
} ?>

The the_excerpt() function is used to automatically generate an excerpt. It’s automatic, that’s why it’s simple. Otherwise, I’d have to set up more tags. Under the WordPress panel for that particular post, you can also add in specific text you want to use as an excerpt. I’m going for simplicity, so I’m using whatever WordPress defaults for me (55 words stripped of HTML).

The more tag is actually typed out in your WordPress post, so you actually have to (or can) figure where exactly you want the break to be. More control, less automation. It looks like this <!--More-->

The entire if statement is in the main WordPress loop. The is_category() and is_archive() functions should be self-explanatory. The third condition is a little complicated…

What I want is to customise the layout of the home page. The home page is neither a single WordPress post nor a WordPress page, hence the !is_single() and !is_page(). The $postcounter variable is used to keep track of how many posts were already displayed. The declaration and incrementation of the variable is not shown in the code.

The desired effect is that, on the home page, only the first post (which is the latest) is displayed in full. All other posts on the home page is displayed in excerpt form.

In the else part, it should be either a single post or page, so display the full content. The function the_content() takes a single parameter which is the “read more” text.

I have a customised version of the_content() parameter, which I believe will use any localisation files to translate the given text. If you’re not concerned with it, just use something like the_content('Read more...');.

Hope this helped you in some way.

P.S. Currently, I use 5 posts per display page. If I go to the second display page on my home page, the first post (the 6th post) displayed is in full, whereas the rest are in excerpt form. It’s not a critical issue, so I’m letting it be…

Basic colour theory for programmers

Alright, this is a crash course in basic colour theory. If you’re a game programmer, or web developer or anyone who will deal with colour at some point in his programming career, what you will read here is crucial. Let’s begin.

Colour models

You will most often deal with the RGB model, where red, green and blue are the primary colours. It’s an additive model. This is the traditional “adding” of colours together to produce new colours.

There’s also the CMYK model, referring to cyan, magenta, yellow and black. K is for key colour, and black was used. It’s also a subtractive model. It’s subtractive because mixing colours together prevents certain wavelengths of light from being reflected.

[Short digression]
When you see a blue cup, what happens is only wavelengths corresponding to the blue colour is reflected off the surface of the cup. All other wavelengths are absorbed by the cup. That’s why you see blue. You might find it helpful to review your science lessons…
[End digression]

Then there’s the HSV model, referring to hue, saturation and value. Some similar notations are HSL, HSI and HSB. The difference is lightness (HSL), intensity (HSI), and brightness (HSB). There are some differences between them. We’ll concentrate on HSV here, and you’re encouraged to read up on the others.

Hue refers to the colour itself. Saturation refers to “how much” of that colour. And value is “how light” is that colour. It’s a bit hard to explain. I’ll show how this looks like in a section further down.

What’s the deal with red, YELLOW and blue then?

If I understand it correctly, it’s basically a misunderstanding (read more about RGB and RYB). RGB is used in light-related situations, such as television and computer monitors.

The RYB model is a simplification of the CMYK model (as I understand it). It’s not easy for mortals to associate cyan with blue, or magenta with red… Can you imagine teaching a 6 year old to say “magenta” instead of “red”?

The RYB (or CMYK) model is used in pigment-related situations, such as printing and painting. Our water colour and crayon art classes fall into this.

Why do you need to know this? Normally, you don’t need to. Unless you’re writing code for a printer driver. Then this difference is crucial to your understanding.

Colour representations

You might have created colour wheels in your science class or art class (I created mine in an art class). It looks like this:

Colour wheel
[original image]

Then there’s the colour cone.

Colour cone
[original image]

This is the usual HSV representation. Hue refers to the edge of the circular plane containing the “pure” colours. Saturation refers to how far the colour tint is from the centre of the circle. The closer a tint is to the centre, the whiter the tint. The closer a tint is to the edge, the more saturated the tint is with that particular “pure” colour.

Value refers to how light the colour is. Visually, it’s how close a tint is to the circular plane. The lower the value (close to point of cone), the darker the tint. The higher the value (close to circular plan), the lighter the tint.

You might find it useful to play around the colour control in Paint.NET:

HSV controls in Paint.NET

And then we have the colour cube, which might be easier to understand:

Colour cube

Red, green and blue values are used as the 3 axes, similar to our 3D X-, Y- and Z- axes.

We see more than is representable

Humans see a greater range of colours than is represented. Have a look at this:

Visible colour range
[original image]

You see that triangle there in the centre? That’s the representable range of colours. We see a whole lot more colours than our computers can represent.

Notice how much more green we can see? A possible reason is our ancestors lived in an environment surrounded by plant life (no citations… remnant from my early student days…). Maybe we needed to distinguish more variations of green…

It’s also a reason when colours are stored in 16 bits, green is given more priority. 5 bits for red, 6 bits for green and 5 bits for blue. We’ll look at this in a future post.

Colour temperature

This section deals with subjective opinions about colours. As a programmer, you’re probably not too interested in this. But if you’re a web developer, or a programmer pressed into design work, you should care about this.

So, there are warm colours and cool colours. Warm colours typically include the reds, oranges and browns. Cool colours typically include the blues, greens and greys. Warm colours incite feelings. Cool colours calm feelings.

There’s this internal web application I’m maintaining. The user interface is almost totally “warm”. The header is red. The datagrids are red. Buttons are pinkish. Oh my goodness, how can a user come to a screen like this and not get angry?

On a usability point, how can an error message be displayed so the user takes notice of it? Error messages are typically in red, or highlighted with red (or warm colour) backgrounds. Since everything is reddish, nothing stands out.

There’s no excuse for making a simple design mistake like this, even if you’re “only a programmer” and not a designer.

Colour contrast

A basic contrast principle is this: 2 colours opposite each other on the colour wheel form a contrast pair. For example, blue and orange form a contrast pair.

It doesn’t mean they form the best contrast pair. But it does give you a starting point. Orange and green is fine too (I didn’t say they’d be pretty…).

For web design, 3 base colours are usually chosen. (Sorry, I can’t find any reference on this. Purely from a vague memory in the recesses of my brain…) A rule of thumb is to choose 3 colours on the colour wheel such that they form a triangle. For example, red, yellow and blue. Or orange, green and magenta.

This way, the 3 colours form enough of a contrast to each other. But it will look terrible if every colour on a web page contrast with each other. Which brings us to…

Complementary colours

Complementary colours enhance each other. For example, red, orange and brown. Or green, blue and yellow. How do you choose them? They are next to each other on the colour wheel, give or take a couple of colour steps.

How does this work with contrast colours? Choose a predominant colour out of the 3, then choose complementary colours based on this predominant colour. Use the predominant colour and its complementary colours throughout the web page/application, and use the other 2 for contrast.

End of crash course

This has been quite long already, so I’m wrapping up. Understand the different colour models, colour representations and basic colour relations. This is ground work for future posts.

My plan is to slowly work towards 3D programming, and I needed to start off with basic colour theory. It’s going to be hard to explain diffuse colours, ambience, and specular highlights without this. Which are used in understanding 3D rendering. Which is used in games.

Exciting, right? Stay tuned.

Be careful when timing one-liners

Be careful when differences between your timing tests are one-liners, and these one-liners are the entirety of your timing code. This applies to small chunks of code too. I’m actually extending a remark I said while discussing multiplications, additions and bit shifts:

This allows you to increase the percentage of identical parts between the tests, and thus highlight the difference in only the calculation method

The small code chunks you’re testing are sensitive to timing, meaning their timing results are likely to fluctuate. Instead of testing the code chunks in isolation, surround them in code used in a typical situation. Why should you do this?

Suppose you’re testing 2 methods. In isolation, method A took 2 seconds. Method B took 5 seconds. Wow! Hands down, method A is faster than method B.

Then when you use method A in production, you find no real speed benefit. Why?

Because in a typical use situation, the surrounding code together with method A takes 60 seconds. A 3 second savings isn’t much. In reality, it doesn’t matter which method you use. Practically speaking, they took the same amount of time.

This was what I meant by increasing the percentage of identical parts.

A physics experiment: timing falling balls

Suppose you want to time how fast a ball falls from a specific height to reach the ground. You start with experiment A (shown in picture), with a low height.

Timing falling balls

Then you try starting from a higher height, say 3 times higher, in experiment B. You take your measurements and do the relevant calculations. Taking into account the different heights, you divide the timings in experiment B by 3 to normalise them with those of experiment A. And you find they differ quite a bit. Why?

Because you forgot to take into account that when you start and stop a timer, your reaction time comes into play.

Your reaction time took a larger percentage in the total time taken in experiment A because the ball hits the ground fairly fast. In experiment B, the time taken to hit the ground is longer, so your reaction time takes a smaller percentage.

So what’s the larger “percentage of identical parts” in experiment B? Air, or more height.*

* assuming wind and air eddies don’t foul up the experiment