Archive for the ‘Plugins’ tag

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.

Fieldnotes on a WordPress 2.7 Development Build

Over the weekend, I decided to finally install a copy of the WordPress trunk — that’s the currently-being-worked-on version for those not familiar with the term. For need of something to write on that new installation, I noted my first impressions of it. It seems relevant to share as the WordPress team is now soliciting advice about its menu structures.

It worth noting that I did this Saturday. Things have changed since. If you’re interested, popularly relevant information about development is at the WordPress Blog. More abbreviated notes, and up-to-the-day changes are tracked here.

Because some of my impressions make little sense without visuals, I’ve included a gallery of the most notable changes that have so far been made in the progress toward 2.7. (Sidenote: first time I’ve used the gallery in WordPress.)

And now my impressions, as originally noted:

I don’t really like how the new version smashes out the horizontal space. Though I doubt the change is nearly as big as it currently seems to me, it’s undeniable that the compose area fits fewer words per line than did previous (2.6-) versions.

The left side navigation has its pluses and minuses. I like that you can get to any page at all from it, but it’s also there even when you aren’t wanting to go to any page.

I think the term Utilities in the sidebar is misguided. “Manage” seemed to make more sense, and still does.

The built-in browse and install feature for plugins is pretty unquestionably cool.

The built-in upgrade to WordPress itself seemed to have failed on my one and only attempt. (It has since worked for me, the failure may have been a fluke.)

I think the ability to drag anything on the write page the sidebar is good, but it’s not as much customizability as I’d like. Will I ever be able to put a custom field on a post, without having to name that field every time? And be able to put that field right under the title field if I so choose? Until then any changes or not to the Write page will seem rather superficial to me.

There appears to have been few or no changes made to the Themes area thus far.

The dashboard has changed, but right now the utility of the “Inbox” and Quick Post sections, both sitting above the news boxes of 2.5+, are open questions.

Clearly there’s no small amount of work left before 2.7 “ships” in November (by current plans). That said, I’m amazed by all the great features slated for inclusion, and I feel so lucky to blog on such a constantly-improving platform.

Debugging: Random Redirect and WP Super Cache

I think the quip, which I most often see attributed to Thomas Fuller, that “All things are difficult before they are easy” is so clearly borne out by debugging that the truth of it cannot be doubted. You can easily spend minutes, hours, even days bashing your head against a metaphorical wall only to notice that a misplaced colon — which you of course, didn’t realize was misplaced — was the cause of reams of unnecessary pain.

The Problem: Incompatible Rules

During my work on Kaleidoscope, that’s the theme this site is running, I decided that a random post link in the footer would be nice. A quick search yeilded Matt’s Random Redirect Plugin, which was more than up to the job. Without a need to reinvent the wheel, I just borrowed the core functionality of Matt’s plugin function and dropped it into my theme’s functions.php file.

And on my personal test server, it worked well. And when I put it on the Ikiru Demo Blog, there too it worked fine. But I found problems on Ikiru Design. More frustratingly, those problems would sometimes seem to suddenly disappear. (It was only later that I realized that it was whether or not I’d logged in that was the cause of that disparity.)

As you may suspect from what I’ve said so far, Ikiru Design has the WP Super Cache plugin running (though it has rarely needed it). Looking desperately to figure out why my redirect link in the footer worked on the demo blog but not on the main one, I decided to look through their directories.

Solution One: Changing .htaccess

Mercifully, I noticed that the .htaccess files were drastically different sizes. And I remembered that SuperCache depends on your making changes to that file. And indeed, comparing the two showed these lines added to Ikiru’s .htaccess file:

# BEGIN WPSuperCache

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{QUERY_STRING} !.*s=.*
RewriteCond %{HTTP_COOKIE} !^.*(comment_author_|wordpress|wp-postpass_).*$
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html.gz -f
RewriteRule ^(.*) /wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html.gz [L]

RewriteCond %{QUERY_STRING} !.*s=.*
RewriteCond %{HTTP_COOKIE} !^.*(comment_author_|wordpress|wp-postpass_).*$
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html -f
RewriteRule ^(.*) /wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html [L]

# END WPSuperCache

I now understand what this does, but at first I didn’t. It looked like a mash of random characters. But I know enough about programming conventions to guess that an “!” means not. And I also know enough about this modern world to know to Google things I don’t understand. “RewriteRule” seemed a reasonable phrase to start with.

I’ll spare you the full narrative of the search, but I’ll explain what I learned. RewriteCond provides the conditions that determine whether or not a RewriteRule is used by the server. Essentially, if a user trying to access a given file on the server gets through all the conditions in the RewriteCond stack, they’ll be made to follow the RewriteRule.

In this case, that means that if their query string — that’s the ?s or ?p=187 or ?random that tells the server what dynamic features are wanted — doesn’t start with ?s, and if the user doesn’t have a cookie specifying that they’ve either logged in or commented, and if the proper static file has been generated, send them that static file. (You see essentially the same rules there twice, the top one is for if you’re using compression, the other for if you’re not.) This is exactly how Super Cache is advertised to work.

But it means that the server will ignore the query string ?random that Matt’s Random Redirect function relies on. So the user will get, as I was, the cached version of the index page. And they’ll get it before Matt’s plugin has had a chance to well, redirect them.

Having figured that this was what was probably happening, I felt reasonably hopeful that I could finally fix this week-old problem. After all, the random link was working when I was logged in — thus not making me follow the RewriteRule — but it was failing when I wasn’t.

So I added was this line to the RewriteCond stacks:

RewriteCond %{QUERY_STRING} !.*random*

This adds an exclusion, which says that if the url looks something like “”, exclude the user from the RewriteRule. Uploading the modified file and opening the link from every conceivable page I could find showed that it was finally working.

Solution Two: Changing the Function

But this can’t be packaged into a theme. Fortunately, a usable but imperfect solution can be. The basic problem is that redirects break with WP Super Cache. The solution is to do this same thing without a redirect.

Essentially, all this take is simplifying Matt’s Random Redirect Plugin even further. The result was this function:

function sc_safe_random() {
	global $wpdb;
	$query = "SELECT ID FROM $wpdb->posts WHERE post_type = 'post' AND post_password = '' AND post_status = 'publish' ORDER BY RAND() LIMIT 1";
	$random_id = $wpdb->get_var( $query );
	return get_permalink($random_id);

This is essentially the first three lines of Matt’s function — which picks a random post from among those eligible on your blog — and adds a line that just tells it to pass the permalink for that post to the place where the function is called. Then you simply call the function for your random link, like:

<a href="<?php echo sc_safe_random() ?>">a random post</a>

This solution works, but it’s got a problem. If I were to click the redirect version into five new tabs from a single page, I’d receive five tabs each with a different random post in it. If I do the same with this version, I get the same post each time.

The likelihood of someone doing this is obviously questionable, but it’s a feature that I’d rather not lose. For that reason, I’m planning on making sure that I allow a user who doesn’t have WP Super Cache enabled, or who have implemented Solution One, to use the redirect version. Those who have Super Cache enabled, or who don’t mind the limitations of this second solution, would be able to continue to use it.

A Better WordPress Monthly Archives

If there’s one big problem with WordPress (and blogs in general) it’s that posts come and go very quickly. This is great for people who are embarrassed by what they’re writing, but for the average person this can be a great disappointment.

It also doesn’t help the case that WordPress’s default Archives page is ugly and hard to use. Nor that most free themes that contain an Archives page aren’t much better.

WordPress Default Archives

Since you may be a little confused, dear reader, some visuals. The default WordPress archives page (that’s archives.php for those keeping score at home) is pictured at right (click for bigger).

Anyone who’s ever used it will know that they’re taken from the monthly link to pages that simply show all entries from that month in full form (this time we’re talking about archive.php sportsfans). The format and contents of those pages doesn’t concern us now, as it’s a long-standing — even if unwise — tradition that clicking “February 2007” on the blog of anyone mildly prolific is a dangerous idea.

If you look very hard at improving the Archives page in WordPress, you’ll quickly come to understand why they tend to be so sub-par. WordPress’s native function to create archives (wp_get_archives) is frighteningly limited in it’s abilities. I’ll spare you the details, but suffice it to say that nothing it outputs is much better than what we’ve seen.

Since WordPress itself fails, a different application is needed. Having already found Justin Blanton’s Smart Archives plugin — which I used to make my archives at Frozen Toothpaste more presentable — I decided that was a good place to start.

Frozen Toothpaste Archives

As the Frozen Toothpaste archive shows (see left), the Smart Archive plugin allows you to cleanly display all the your writings from a given month listed chronologically. This, I decided, was the Archives page I wanted my themes to have.

But requiring plugins for a theme to work is fraught with problems. It requires more work than the average WordPress user can or wants to commit to. So however I made my archive, it had to be inside the theme. The easiest way to do that: include the plugin on the page that creates the archives — archives.php.

Though I’m neither a PHP or server-load “pro,” I couldn’t find much of a downside to to putting the code from the plug-in on the page (if you are such a person and can tell me that there is a problem, please do). And, better still, doing so would make the creation of a nice monthly archive as easy as the creation of a default poor one.

Carter’s Line Achive

So essentially, that’s what I did. I did do a great deal of shrinking and modifying of Mr. Blanton’s plugin, but it meat of it is still intact. Most of my cuts were becuase I required it to do far less than the plugin can. I wanted the code as lean as it could be while still providing the necessary function, which I think it does. To see my archives.php page it in action, just head over to the Ikiru Demo Blog and look at it on any of my themes. (You can also see the Archives page on WordPress’s default theme for comparison.)

And if you’re looking for something even more fancy than the Archives pages provided by Smart Archives (in or outside of) my themes, I’d suggest that the best place to look is Clean Archives which is both flashier and larger than the Smart Archives plug-in. Though these characteristic were detrimental to my need here, they may be exactly what you’re looking for.