The Pros and Cons of Moving to WordPress Multisite

It’s not a problem many people have, but for the rare person who suddenly looks down and realizes they’re updating WordPress, its plugins, and themes across many different instances each time they change, the siren song of a multisite WordPress install (previously known as multi-user, or WPMU) is strong. And since they integrated this feature into the WordPress core back in 3.0, that call has only gotten stronger.

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.

The Best Free WordPress Backup Plugin I’ve Found

If there’s one thing I’m certain of in the world of computers, it’s the value of a good backup. A good backup has three traits:

  • 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 New and Much Improved Mini Quilt Plugin

After having done some work on my date-to-color algorithm, I got to thinking about all the weak points in the first and only WordPress plugin I’d published, Mini Quilt. While I do think that the quilts it created were pretty, they had a single and very strong weakness: without hovering there was no way to know anything but the approximate date of the posts it was linking to.

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.

Three iterations of the widget running on Automattic's Coraline theme

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!

How I Made an Annual Color Algorithm

The foundation of my Kaleidoscope theme and Mini Quilt plugin is the color algorithm. For those who don’t know, the Kaleidoscope theme for WordPress is a simple theme I made (almost three years ago) that changes the colors of its pages based on when posts were written. (It’s the theme currently being used here.) It features quilts, which show recent posts in blocks of color. The small multicolored quilt in the sidebar of the theme is available separately, and can be added to any theme as a sidebar widget with the Mini Quilt plugin.

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.

Twice Monthly

I’ve been giving it some thought, and I think I’ll be better off publishing this site twice a month rather than once. Doing so will allow my to keep momentum, and make me feel more comfortable publishing more “here’s a thought or plugin you might not know” stuff. So instead of the first of every month, I’ll be publishing here on the 5th and 25th of every month. (If you’re wondering why such odd dates, it’s because I like the number 5 and these comfortably allow me to keep up my every 15th schedule at Frozen Toothpaste).