If there’s a single reason I maintain a website devoted to working with WordPress, it’s this: WordPress is the best tool that currently exists for internet publishing, and my primary goal today is to be an internet author (and by extension publisher). My goal, with all things I create is to make better WordPress tools that help internet publishers to makes better looking, more approachable internet content. Even if no one but me ever finds value in the things I create and share here, the tools and learning I put here will have helped me to become a better internet publisher.

It’s not about making money. It’s not about making the kind of things that get me copious internet traffic. It’s not about getting people to hire me to do things with WordPress for them. It’s about making better, more approachable, and thus more read, internet sites using WordPress. That’s it.

Quickly though, here is the basic progression of how I’ve tried to add CSS to plugin output in the past.

1. Doing it purely inline with <style=" ... ">. (This does have a very small place on the internet — when you truly want to apply a unique style to a single element — but I wasn’t using that.)
2. Adding bare CSS with an action hook to wp_head. I was just spitting it all in the head of theme making the files bigger, and the source more convoluted.
3. Appending my own .css file with a script I found somewhere and didn’t really understand.
4. What I’m about to show you: Appending my own .css file, but allowing the theme to replace it by putting sensibly named alternative in it’s style directory.

Essentially, for that Post Meta Box plugin I mentioned in the aforelinked post, I wanted to be able to modify the basic styling but not affect all the places I’m trying to use it. So, I did what made the most sense to me, copied the master CSS file (postmetabox.css) to my active themes directory and modified it there. And because this script I’m about to give you is so smart, that became the active styling without any problems. So here it is:

(A quick note: I’ve kept all references to “pmb”, my shortcut for making things local to my Post Meta Box plugin. If you’re using this function, I’d do a find and replace with whatever shorthand you use to refer to your plugin. I could have find-and-replaced it to “my-plugin,” but we’re smart people, so I’ll spare us that unnecessary step.)

add_action('wp_print_styles', 'add_pmb_stylesheet');

function add_pmb_stylesheet() {
	$theme_style_url = get_stylesheet_directory_uri() . '/postmetabox.css';
	$theme_style_file = get_stylesheet_directory() . '/postmetabox.css';
	$pmb_style_url = plugins_url() . '/post-meta-box/postmetabox.css';

	if ( file_exists($theme_style_file) ) {
		wp_register_style('themepmb', $theme_style_url);
		wp_enqueue_style( 'themepmb');
	}
	else {
		wp_register_style('pmb', $pmb_style_url);
		wp_enqueue_style( 'pmb');
	}
}

First and foremost, that add_action call is (half of) the proper way to append any stylesheet in WordPress. There are many other things you can do that will function for you (the aforementioned wp_head method is probably the worst of them). Essentially, all it’s doing is calling my function when it gets to any place it typically reaches for style sheets.

So what our function does is hand it the right style sheet. And which stylesheet is right depends on whether or not the user has created one for their current theme, or if they just want to rely on ours. So essentially, we’re just looking to see if the user has created the file to hold their own stylesheet ($theme_style_file), if they have, we use that. If they haven’t, we use our own.

There’s nothing in here that a seasoned PHP and WordPress person should be stunned by, but there’s a lot of little bits that your average tinkerer will not have known about. Like that PHP can easily check if a file exists — that function’s in every version of PHP ever — but does it with local addresses, so you need to know where the style sheet is both locally and internet-wise. And the commands wp_regiester_style and  wp_enqueue_style — which round out the proper way to add a style sheet — were completely unknown to me until I ran across a little tutorial (by I think Justin Tadlock, though after 20 minutes of looking I gave up on definitively finding who it was).

I wondered for some time about the possibility of keeping some sensible defaults for my plugin’s visual output and always using them, but if for some reason the user wants to overwrite what seem to me to be sensible defaults I want to make that easy. And since I think most anyone inspired to modify my styling would take the sensible advice to copy the original file and put it in their theme and modify it there, that’s what we’re allowing for.

It’s entirely possible that another years of dinking around with WordPress will convince me that this method is as foolish, or outdated, or bad, as my previous methods, but the more I think about that the less likely it seems to me.

Over the weekend, I finally did some work I’d been meaning to for a while. I moved the “post meta data” — tags, similar posts, last and previous post links, etc — which I used to have in the sidebar of Frozen Toothpaste back to the bottom of the posts. (Every post on the site will show it, but this is a shorter one.) It seems obvious to me (now; there’s a then when it wasn’t) that this is the right place for it to be, there for when someone has finished with one post and can easily get a good “next action” right there, rather than scrolling back to the top and then looking to the sidebar.

All of that’s tangential to the point that when I started to build this new “post meta box” I went to start writing the code for it into my current theme. But I’ve meant to change my theme for nearly a year, and it occurred to me that it would really suck to have to move all this code over next time I change the theme.

So I went with the obvious solution to this problem, and the best answer to the generic question of “Well, then where should I put code that does stuff in my theme?” I made a plugin.

Some of this is simply personal preference and coding style. There’s probably a reasonable argument that could be made for keeping at least some of the code that makes those post meta boxes appear local to the theme. I’m convinced it’s possible that you could convince someone of that argument. But I doubt you could have convinced me that’s what I should do for me. And that’s really all that matters. If you can’t convince yourself it belongs in the theme, it doesn’t. If you’re able to convince yourself, do whatever you like.

To most people who spend a significant amount of time futzing with WordPress plugins and themes, this is probably self-evident. But I struggle to recall a time when I didn’t make at least a few poor decisions because I’d never heard the pretty damn good advice: if it doesn’t obviously belong in your WordPress theme, don’t put it in your WordPress theme.

WordPress as a whole — the community more than the tool — is less-free now than it was a year ago, and less so still than it was five years ago. That’s the nature of what I see as the problem. But the reason I’m so tentative to call it a problem is that WordPress is also a far better tool now than it was a year ago, and certainly far more than it was five years ago. And like it or not, I think this fundamental creeping unfreedom has, at the least, contributed to the rate at which WordPress has become a better tool than it has ever been.

In my estimation, the first foot-fall of this unfree menace (again, I say that but don’t wholly mean it) were the “premium” themes. Someone, I think it was Brian Gardner, had the reasonable thought that rather than making money solely by purpose-building WordPress themes for clients paying $500 and north, they could fill a market-gap with a well-made theme priced around $100. For users who wanted more than a free theme could give them, but less than hiring a designer would, they got a product that pretty well sat that gap.

One could debate endlessly whether there are more or less good free themes being made today, but judgement about that is inherently subjective and thus not worth making. What is almost certainly true is that free themes are no longer the only non-exclusive themes that exist. And while I, as a rather poor person certainly preferred it when all themes I could hope to use were free-as-in-beer, it’s not an unmitigated catastrophe that they aren’t.

It is worrying how likely it is that because “premium” themes aren’t free-as-in-beer, they’re not building on each other. Being harder to get makes them less likely to be publicly modified and enhanced by others, and to be used to make other similar themes better. Again, we need to balance these facts with the fact that there are more better-quality themes generally, etc, but the effect is not negligible.

Now the other day, the WordPress.com Stats plugin declared to me it has been discontinued in preference to Jetpack, which Automattic portrays as the plugin to “blast-off” into the fun world of WordPress.com features. It’s also, almost certainly, going to give Automattic a convenient place to get self-hosted WordPress users to enter the world of paying for some features, as has always been the available on WordPress.com.

Again, this isn’t ransom or anything. It’s a completely sensible — even admirable — business move, but it’s not exactly fostering freedom and building better software for all users. How many features might not be built into the core of WordPress because Automattic has a money-making Jetpack feature that does the same thing? (Is the reason there is no backup functionality in the WordPress core that VaultPress exists?) Questions like this always contain some alarmism, but that doesn’t mean we should just ignore the potential for a conflict of interest.

These type of vague but indefensible concerns are precisely why I bristled at the thought of replacing what was a relatively lean and fast plugin with the colossus that is Jetpack. I have no concrete reason to think the WordPress core will suffer so Automattic can make more money, but that fact that a I’m seeing more and more avenues by which this could come to pass definitely gives me pause. And that, I guess, is all I’m really trying to say.

It was while I was giving this idea some further consideration recently that I  recalled a plugin that was featured on WPCandy. When I first saw Blog Update Reminder I couldn’t really think of a reason I would use it. But giving some thought to trying to update my blogs more frequently it suddenly occurred to me that it would be pretty cool if I could just get some kind of alert that it had been a while since I’ve posted and maybe I should.

And this is exactly what Blog Update Reminder does. If you haven’t published a post to a blog in a set interval of days, it sends you an email that says something to the extent of, “Hey, maybe you should update.”

It’s also worth noting that, at least for now, scheduled posts count toward the good. That is: if I have a post scheduled for a week from now and I set my pester interval to two days, I won’t get bothered until two days after I have no more scheduled posts (nine days). So you could cheat the system by scheduling a post far away and never publishing. But it’s a tool meant for your benefit, not your pain, so I’m not sure that really gets scored as a problem.

Mostly I like the idea of the plugin as a way to keep me honest. The game can be built so that with scrupulous posting I’ll never see a reminder. Such that when I see the reminder I know that I’ve lost the game. It’s only when I’ve failed to maintain the frequency with which I intend to post that I’ll get reminders (or notifications of defeat).

Substance-wise, I only have two potential niggly points about the plugin. The first is the name. Anytime I see someone uses the word “update” with any proximity of the word WordPress, I think of the need to keep my blog software up-to-date for security and feature reasons, not publishing stuff on my blog. I’d have called this plugin something like “No Post Pesterer”. Yes it’s a trivial point, but I warned you these were niggly.

The other issue is that I can’t know what the email message will say short of editing the plugin or falling delinquent myself. Again niggly, but I’d love to be able to send a test email to myself, and easily set the email message to say:

Hey Loser,

You’ve been neglecting your responsibility to yourself and your readership by not updating [blogname] in [dayssince] days. Remember, you think you should post every [setinterval] and you’re letting yourself down by not keeping up that rate.

Obviously coding the ability to easily customize the message text is a nontrivial task, and probably not really worth it for the modest benefit it provides. The stock text is a little more formal than I am with myself, but that never did anyone any harm. And editing it in the plugin itself is hardly rocket science.

Overall, I’m excited by this plugin that I didn’t understand initially. I think it’ll be a great excuse for me to see if I can keep myself posting to my blogs with a reasonable frequency with just this single modest crutch. And if you think you could use such a crutch, this seems like a good one.

I’ve been idly thinking about how good this could be every time a new version of WordPress drops and I’m forced to manually go through each of the five instances of WordPress I maintain online for personal use and update them. Mercifully, this has become massively easier in the last few years, but it’s still an annoying and time consuming process compared with updating everything once.

Since laziness drives many of my technical decisions, I know I’m not likely to take the time to do this without a thorough consideration of the things gained and lost. And since I feel rather confident that this could prove valuable for another person who finds themselves in a similar situation, I’ve decided to weigh the value of the transition in public. So here it is, a list of what I see as the good and bad parts of migrating mulitple disparate WordPress installs to a single WordPress Multisite one.

The Good

• The aforementioned maintenance benefits. Being able to update WordPress once is unquestionably better than having to do it multiple different times. The same goes for keeping plugins and themes up-to-date. Once is massively better than five times.
• Plugin propagation. Similarly, when I discover a new awesome plugin with my current setup, I have to manually put it on every blog on which I want to use it. Because with multisite you keep plugins in one place and use them on all blogs, it’s a clear win.
• New blog creation is easier. Five already seems like too many for me, but I still think about the possibility of creating new sites for various reasons. The ability to just start a new blog without having to reupload WordPress, never mind populate plugins and themes, is huge potential benefit of this process.

The Bad

• Upfront costs. These are numerous, and non-trivial. Essentially, to get all the long-term maintenance benefits requires a lot of one-time costs in the form of exports, imports, and setting resets. The export/import process to move your blog posts along couldn’t really be simpler. This process, however, doesn’t include the blogroll, plugins and settings, widgets, and your blog’s tagline. And we haven’t even considered the headache of a nearly inevitable period of polluted RSS feeds and unreadable sites.
• The learning curve. While WordPress Multisite isn’t hugely complicated, there are a number of things that work differently than with standalone blogs. Thus there will inevitably a period of ignorance and learning, even if short it’s not negligible.
• Embedded HTML. This isn’t one I’d been aware of before investigating, but because Multisite is built for creating a blog network that the general public can use, they made reasonable security concessions in curbing your ability to use <iframe>s and <embed>s which could be a headache if you’ve used them for say, Amazon affilitate panels in posts, embedded YouTube videos, etc. There are solutions to this issue, but it’s definitely a potential problem.
• Those upfront costs again. I’m not kidding. If you’re not completely comfortable with either server or WordPress administration this is significantly more complex than a standard WordPress install. And if, like I would be, you’re doing it in an existing account at the same host, you’ve got a bit of an acrobatic headache ahead.

I’m not fully decided on the question of whether or not I’ll do it. I do have to say that making the list has already made me think that maybe my reason for wanting to do it is a bit ill-considered. I think for now I’ll personally keep playing with the one I’ve already setup in my development environment and see how I like it. So for me at least, the idea is currently on hold.

• It’s effortless.
• It captures everything you care about.
• It can easily be used to make things as they were.

For a long time, my WordPress backup was one of these three. I’ve been using WordPress Database Backup since I started using WordPress. It is great at doing what it advertises: backing up your database. But that’s all it does. So all your themes and plugins, all your uploaded photos and movies, everything that doesn’t reside in the database isn’t backed up.

I was able to justify this to myself because there weren’t many good backup solutions for WordPress when I started using it four years ago. And mercifully, my web host never had any catastrophic loss of data that made me regret my laziness. But depending on any single entity (including yourself) to not use lose your data is foolish.

When VaultPress came out I thought (for a second) that it might be my long awaited solution. And though I’ve never used it, I’m fairly confident that Automattic has created the best WordPress backup (and more) product available on the market. If you use VaultPress, they’re backing up your whole blog at sane intervals and make restoring from those as easy as it can be. It fulfills all three of the mentioned criteria, but at a minimum of $15 per site per month costs way more than I’m willing to spend to back up my three blogs. (If I didn’t have three, I’d have been far more likely to take that rate seriously.)

With the potential for an official free solution looking dim, I started thinking about other options. When Roy Tanck blogged about a Dropbox-utilizing option last November, I was intrigued. (I, like most of you, have a Dropbox account with plenty of space left. If you don’t have one, go signup. It’s free and a great way to access your files from anywhere.)  But when he mentioned that making it work well would require setting up cron jobs, the laziness that had me only backing up my database beat out my desire to have this issue solved.

And then, a few months ago I saw on WPCandy Michael De Wildt’s WordPress Backup to Dropbox plugin and there finally seemed to be an easy-enough solution. It’s not a perfect solution (more on that in a bit), but it’s easy enough and complete enough that I finally, for the first time, have full backups of all my WordPress sites that I can use to quickly restore things to a pre-disaster state. There’s no need to create a cron job, no need to do anything much at all once you’ve set it up and told it when you want to backup your stuff. It just works seamlessly, only alerting you to its functioning when Dropbox tells you that it’s pushing the backups to your computer.

As I said though, it’s not perfect. The highest number of demerits are due to the setup. It can be a bit of bear, especially if you’re not all that comfortable with web server administration. It’s not that the plugin doesn’t work, but that depending on your hosting plan you’ll have to figure out how to change a few PHP defaults that can stop the plugin as it works.

To save resources many hosts use low defaults for things like the time a process can work (max_execution_time) and the amount of memory it can take (memory_limit). This isn’t a problem for something like WordPress where no process monopolizes many server resources, but building and uploading a backup takes time and memory greater than my default PHP install permitted, and this meant it was killing the process the plugin was trying to use to do it’s work. (If you’re wondering, I believe the defaults in my host’s php.ini were 60 and 8M, the values that I used to get the plugin working without error are 600 and 128M.) My defaults seems a bit anomalous, and De Wildt has also made great strides in minimizing these problems by changing the way the plugin works, so it’s entirely possible you won’t encounter these issues.

Nonetheless, this default problem can easily lead to you thinking your data’s secure when it’s truly not. And this is where the plugin could be better: when backups fail repeatedly, it would be good if users would get a big warning on their Dashboard announcing that their data isn’t secure. As it is, you have to go to the plugin’s setting page to find out that the plugin you were running for two weeks never managed to do much of anything.

Finally, it’s worth touching on restoring, which is not currently something the plugin will do for you. If you have a catastrophic loss of data, all you need to do is upload the data the plugin has downloaded and import the database backup into your new MySQL instance. In the interest of being thorough, I tried this locally and it seems to work just as expected. All my plugins were running, my pictures were there, and my themes were available. It’s not the easiest imaginable restore (I’m sure many people are still scared by phpMyAdmin), but I don’t think there’s a better option available for no charge.

Even with my noted issues, I can wholeheartedly say that WordPress Backup to Dropbox is the first WordPress backup plugin that I feel satisfies all three of my essential backup criteria without costing more than I’m willing to spend. If you run your own WordPress blog and aren’t currently running a thorough backup plugin, you no longer have a good excuse.

The fact that there was no way to know post titles — or anything else — without hovering with your mouse pointer wasn’t a problem I grasped while building it because hovering over links to see what’s under them is second nature to me. But as time passed, I noticed two situations where even this excuse was failing to justify the poor design decision.

The first is browsers without a persistent information bar. If you don’t know, the information bar was a compulsory part of browsers until, I think Safari (though it could be Chrome). This was a bar at the bottom of every browser window that would show you the addresses links pointed to when you hovered over them, as well as offer other details about browser plugins you might be running, popups the browser blocked, and in the real old days, the load status of the page you were looking at. With that going away, you could still get some good information by hovering long enough that the link’s title would appear beside your cursor. But that was at best slow and of moderate usefulness.

Besides, the other problem made that way of dealing with the problem irrelevant. In the last five years, there has been a vast increase in use of touch-based computers for web browsing. Essentially from the time the iPhone brought the full web to cellphones, there’s been a rapidly growing contingent of people who may see your blog but have no way at all to hover over links. The only way you can find out where a link points with a touch-based browser is to visit it. So without a way to get any description of what was behind those colored boxes, they were really just mysterious distractions.

In the latest version of the plugin I’ve solved that problem by making it possible (but not mandatory) to show the title of the posts that a patch corresponds to. This way quilts are like a more visually interesting list of recent posts, rather than a mere pretty accoutrement for your sidebar (not that there’s anything wrong with that).

I’ve also, because I thought it would be fun, made it possible to randomize a quilt, putting posts into random rather than reverse-chronological order. And because of the randomize option and the proliferation of widget areas in themes, it’s now possible for you to literally use the Mini Quilt widget 1,000,000 times in 1,000,000 different widgetized ares. I hope for your sake you don’t have that many, I’m just letting you know it’s possible.

Finally, and least important to most users, I’ve greatly cleaned and polished everything under the hood so that it’s vastly easier to modify and much easier to understand. (As I broke into the code after two years, there were a number of things that I couldn’t make sense of, so someone who hadn’t written it almost certainly had no hope.)

Enough talk, let’s see it in action. Because this screenshot captures the whole thing so well, it’s the only one I’m offering. This is three different instances of the Mini Quilt widget being used in the Coraline theme. The big one is showing post titles and is arrayed as a quilt.

The second (left side) one is what I call a “Mini Bar,” it’s a single column (hence bar) of patches with the titles visible and the columns wide and the heights automatically tall enough to hold all the words of the title. This one is also randomized, choosing just five posts at random from among everything you’ve ever published. (For the sake of CSS, you can’t have a conventionally blocky quilt with variable heights. Well, technically, the plugin does allow it but it looks like junk and isn’t recommended.)

The final (right side) instance is the traditional old Mini Quilt, much as it was with the original plugin. The only difference is that this one is randomized. Thus there’s not the gradual gradient you can see in the first quilt, but rather random and abrupt color changes. Like I’ve described, there’s no way someone on an iPad will know anything but the date of the posts those patches represent unless they tap them, but it does have a visual charm that the other layouts could be seen to lack.

That’s what’s new in the updated version (0.8.0) of the Mini Quilt plugin, which you can get from the Extend WordPress plugin repository or simply by simply clicking Add New from the Plugins menu in your WordPress installation and searching for Mini Quilt. Enjoy!

Both the theme and plugin are rather primitive by today’s WordPress standards because they’ve seen no changes in two and half years. But their current outdatedness is irrelevant to value of the underlying color algorithm. This article exists because someday someone may have the same idea I did and find this guide of what I did — both programmatically and philosophically — helpful. They may even find it useful to just lift my code — which is all GPL licensed — and use it as is. I’m not entirely satisfied that the methods I used here are the best possible ones, but I feel certain that anyone interested in the idea will benefit from knowing them.

The Mother Function

Let’s start with the primary function that either my theme or plugin calls. (Technically the currently available versions, call a similarly named but different function. As I’ve been working on getting better at web stuff, I decided to recode that version. If and when I update the theme or plugin, they’ll have this algorithm.)

function date_to_color( $day, $year ) {

	$red = color_maker( $day, $year, 20, 134 ); //18, 134
	$green = color_maker( $day, $year, 20, 240 ); //20, 240
	$blue = color_maker( $day, $year, 10, 0 ); // 10, 0

	return $rgb = "{$red}{$green}{$blue}"; //concanate the calculated colors and return them
}

Essentially, this is the function that is called anywhere — in WordPress the call looks like date_to_color(get_the_time('z'), get_the_time('Y')) — the color for a day is needed. You’ll notice that all this does is call the color_maker function three times and then return the concatenated (joined) six digit hexadecimal number to wherever it was called. The one thing I’d call your attention to is that it’s passing along four values to that function — the day and year that are submitted when this function is called, and two values that you’ll see later I call $broaden and $shift.

(If you’re wondering, it is considered good form to name functions you write with a prefix like kal_function_name. This prevents pollution of the global name space. For the purposes of this tutorial, I’ve left off the prefixes.)

The Color Determining Equation

Here we’ll begin the important function, color_maker. I’ve broken it into three separate sections that reflect the conceptual underpinnings of the function. Not coincidentally, when I first made this algorithm (the version that’s currently in the theme & plugin) these three parts were three separate functions. It was only upon looking at what I’d done at some distance that I saw that that was needless complexity.  Anyway, here’s the first conceptual unit.

function color_maker( $day, $year, $broaden=0, $shift=0 ) {

	$in_degree = .986*$day; // from 365.25=>360

	/* pshift =
	New degree value = incoming period shift + degree from year - sine function
	Sine Function = Random value * sine of shifted value
		> This essentially works to make the coming cosine function stay near its peak for a while
		> based on the magnitude of the random value
	*/
	$pshift = $shift+$in_degree-($broaden*sin((M_PI*($in_degree+$shift))/180));

The first line here — one of two that isn’t actually a comment — does a pretty simple thing. It converts from days of the year (of which there are 365.25), and makes that into 360 degrees in a circle. This is utterly straightforward.

The next part is a bit more complicated. Essentially, what we’re doing is getting a value ($pshift) ready for the next step,  a cosine function that really determines the color, by shifting our period values into more appropriate inputs to the next function. For example, January 23 needs different values for red, green, and blue in order to give the color I want. I do that here by shifting each color by the value passed on ($shift) from the first function. My shift values are 134 for red, 240 for green, and 0 for blue. This means that for January 23 we’ll pass along values of about 150, 260, and 20. If you know trigonometry well, you’re beginning to get a sense of what colors we’ll make.

There’s another component here though, which is that $broaden value I mentioned earlier. The need for broadening was something I realized as I started to see the colors the cosine wave function generated. They were frequently washed out and drab. I realized that if I was able to make the function’s peaks broader I’d have more color saturation which would correct that problem. That’s what that $broaden variable and sine function are doing. They’re creating values — with the yin and yang relationship of sine and cosine — that will favor the peaks of cosine and shrink the valleys. I don’t want to get too much into the math here (though if you’re interested I’d be happy to explain further), but just know that the larger the value I passed to $broaden in the first function, the stronger the peak-favoring effect is.

Determining what values to use for $broaden and $shift for red, green, and blue is more an art than a science. It’s where I drew on what aesthetic power I had (and the color accuracy of an uncalibrated old LCD) and where there could be the most room for improvement. To figure out what values to use, I created a page with boxes for each day of the year and fiddled until I felt the basic proportions of red, green, and blue were about right for a given season and day. Had I been using a different monitor in different lighting conditions, I may have settled on different (better) values.

The Darkness Determining Equations

Having gotten a single degree value ($pshift) for each color for a day, we need to make that into a color. That’s what this section does:

	$year_diff = date('Y')-$year;
	$hshift = .08*$year_diff; // to be used for further away years fading
	if ( $hshift > 1 ) { //this assures that the colors are always valid otherwise we could get negative numbers
		$hshift = 1;
	} 

	$HBASE = .82; //the center of the function; set between 0 and 2, lower are more saturated (darker)
	if ( $HBASE > 1 ) {
		$HSAFE = 2-$HBASE; // $hsafe is to ensure no final values greater than 2, which would create invalid colors
	} else {
		$HSAFE = $HBASE;
	}

	/* calced_color ==
	Use Cosine to create a weighted set of results between 0 and 2
	Multiply by 127.5 to get results between 0 and 255
	dechex for results between 0 and FF
	+Change the first (and only the first) +/- to toggle fade/darken
	*/
	$calced_color = dechex(127.5*(($HBASE-($HSAFE*$hshift))+(($HSAFE-($HSAFE*$hshift))*(cos((M_PI*($pshift))/180)))));

It’s important to realize that much of this is preamble. The last line — the one that begins “$calcedColor = ...“ — is the important one. Everything else is just tuning up before the show.

The first part of this related to the year. In addition to deriving a different color for each day, my color function also determines brightness based on age. Two posts from July 5, one from today and one from four years ago, will be noticeably different shades. This means that a quick glance at a color derived from the date can tell not only that a post is from Julyish, but Julyish a few years ago.

To do this we essentially figure out how much the submitted year — passed on from the preliminary function — differs from the current year, and then make an $hshift value for it. Because a post could conceivably be more than 12 years old — which is when they become uniformly black — any value over one that might arise is just adjusted down to uniformly black.

The next block of stuff are a number of constants that I keep around only for the sake of future tuning of the function. $HBASE is essentially what will be the center point of our cosine function, and $HSAFE just assures that no value of $HBASE will break the cosine function. They’re not really doing much here, but if I or anyone else feel like tweaking the function, I’d rather it be easy and obvious to edit than hard. (If you are interested in tweaking, higher values of $HBASE give lighter colors. Setting it to 1.3 gives pastel colors, setting it to .6 gives significantly darker hues.)

Finally we’re to that important final line, which does about twelve different things. The important ones, starting from the right and working left are: uses  multiplication with some $h values and cosine to get a basic value for a given color, and them shifts that around by adding and subtracting more $H values to get a value between 0 and 2. Then it multiplies by 127.5 to get a value between 0 and 255, the limit of two-digit hexadecimal numbers, and converts that number into hexadecimal, yielding a final range between 0 and FF. (Again, vagueness on the math is intentional, because otherwise this thing would be even longer than its current too-long length. I’m happy to provide more detail if desired.)

The Kludge

This final bit is a kludge that I couldn’t find a way around (even while I think there must be one.)

	if ( strlen( $calced_color ) < 2 ) { //single digit calced_color values give invalid colors
	  $calced_color = "0".$calced_color; // so add a zero if it's a single digit
	}	

	return $calced_color;
}

Essentially, after each color’s (red, green, and blue) value was determined between 0 and FF, I had a problem. If the red value was 253 in decimal, that converted to the two digit hexadecimal number FD. That was all well and good, but if the value of red had instead been 3 in decimal I would get 3 in hexadecimal. Because a five-digit color value like 3FDFD isn’t valid, I need to ensure that I instead get 03FDFD, which was assured by this function. Its essential logic is: “Is this number shorter than two digits? If yes, put a zero on the front.” Thus FD stays FD, but 3 becomes 03, and D become 0D.

After that kludge, the function returns its two digit hex number to the primary function, where it’s melded with the two others it derived to give a single six-digit value back to the theme or plugin that asked for a color. Thus given values like 188 (today’s day of the year) and 2011 (this year), it derives this sort of brownish yellow that you’re reading this post on. I think it conveys pretty well the dried out heat that I think of in July. It does this by iterating three time (once each for red, green, and blue) through a function with three steps. Those steps are essentially (1) shift to account for the amount of a given color that’s appropriate for the time of year (2) figure out the two digit hexadecimal value to get the right quantity for that color and (3) ensure success in making a six digit hexadecimal color.

I’ve not cured cancer for you, I know. But I hope I’ve given a new way to look at colors, and some valuable knowledge about one way to play with them. Before I close, it seems appropriate to note that I was turned on to this idea by Shaun Inman, though the implementation is all mine. I’m hoping that if my discussion has gotten you interested in this game, you now have some idea how to start.