Google came out with an experimental specification for websites to provide “hints” on forms, to allow things like autocomplete to work better and be more standardized. Seems useful.

Here’s a quick plugin snippet you can use to make your comments form use this specification. Only Chrome 15 and up is using this at the moment, but in the long run I think most browsers will be implementing something similar to this, since filling out forms is just one of those endless pieces of drudgery that we could all stand to do away with.

Note that your theme will need to be using the comment_form() function call for this to work, otherwise you’ll just have to edit your comment form in the theme manually.

Plugin Name: Add X-Autocomplete Fields to Comment Form
function add_x_autocompletetype($fields) {
	$fields['author'] = str_replace('<input', '<input x-autocompletetype="name-full"', $fields['author']);
	$fields['email'] = str_replace('<input', '<input x-autocompletetype="email"', $fields['email']);
	return $fields;

Simple little bit of code, really. Should work with any theme using the normal comment_form() function call.

Online BackupToday it’s time for another edition of this small series of mine. I know that WordPress plugins are a topic widely discussed around the internet, and that there are myriads of posts on “top 10 plugins for this” and “top 10 themes for that.”

However, this series is not about showing you the next fancy thing … it’s about showing you something truly worth installing. The fact is, you can’t install every plugin out there, and hope that your blog will still be working just fine. Unfortunately, plugins slow things down. The more you have the slower your site gets. That’s why I always advise to use ONLY the essential ones.

What does it all have to do with online business? – Asks you. Well, if your site is running on WordPress, like I’ve been advising since forever, then this series is surely something you should keep an eye on. The plugins I’m presenting might come handy to all kinds of blogs, but they are especially handy to online business designers.

To be honest, today we’re going to discuss a very important matter for ANYONE who has a website. Yes, it’s that important.

The topic is backing up your site.

There’s nothing more angering than sitting in front of your computer knowing that you have just lost all of your data due to a hard disk malfunction. Trust me, I know.

Same thing goes for our websites. If, for whatever reason, we lose the data (posts, pages, all information) published on our sites then in some extreme cases it can even mean the end of our business. Think about it like if you were a bakery owner and the building you were renting would burn down…

Of course, we can’t truly protect ourselves against those kinds of things. But we can get some insurance. Such an insurance – in the online world – is a good backup policy.

WordPress users have it easy. They can download a plugin called Online Backup for WordPress free of charge.

This is a plugin I’ve been using for a while, and it works like a charm.

What it’s for

This plugin allows you to create a full backup of your WordPress site, and then have it sent to an email address or made downloadable.

By full backup I mean both the database and the filesystem.

Where you can get it

First of all, feel free to check out the site of the company that has created this plugin – Backup Technology – here you can find some basic facts about the plugin.

Of course, there’s also the plugin site at –

However, the easiest way of getting the plugin is to simply go to your WP admin panel (log in as the admin), and navigate to Plugins > Add New. Input “Online Backup for WordPress” into the field and the first result that appears is what you want.


You don’t have to do anything more than simply installing the plugin like you would install every other WordPress plugin, then activate it, and you’re good to go.

How to use it

When you have the plugin installed just go to Tools > Online Backup.

Once you’re there you can simply navigate to the “Backup” tab, and perform an initial backup.

There are 3 backup types available (image below).

The first one sends the backup to the shared storage at Backup Technology which you can sign up for. I didn’t because I’m using the plugin to create a backup, and then download it to my computer.

Choosing the third option might not be the best idea because backups can be rather large. Sending a 60MB file via email takes time. It’s much faster to simply download it.

Sexy features

The “Backup” tab you already know, so let’s start from the first tab on the right – “Online Backup Settings.”

This is where you can input your username and password for the storage space at Backup Technology. Again, you don’t have to register an account if you don’t want to. The plugin is fully functional without an account.

The “General Settings” tab is worth looking into because it enables you to encrypt all your backups. The plugin works with some popular encryption mechanisms. The only thing you have to do is input an encryption key.

Encryption is a safety mechanism. It ensures that only someone who knows the key can access the backups.

There are also other setting in this tab, make sure to read through them, but you don’t need to change anything. The plugin is set up optimally right from the get go.

The “Schedule” tab enables you to create a schedule for your backups (duh!). The backups can be run in the background automatically and then made available for download or sent to an email.

The “Decrypt Backup” tab is where you can decrypt your encrypted backups. All you have to do is select the backup file and input your encryption key.

The “Activity Log” tab shows the summary of your previous activity. It’s where you can access all previous backups if you haven’t deleted them.

What I like about Online Backup for WordPress

The simple fact that it works. It sounds obvious, but hear me out. I’ve been searching for a quality backup plugin in the past, and even though there were many possibilities there was always something not exactly right about them.

Some plugins were creating corrupted archive files, others didn’t include everything, or couldn’t create an exact image of the database. I mean, these are things you don’t even notice until you have to actually use the backups.

That’s why I decided to do all my backups by hand because that way I was sure that I had everything I needed to have. However, this has changed when I stumbled upon Online Backup for WordPress. It. Simply. Works.

What do you think about this plugin? Did you experience any problems with it? Feel free to let me know.

Related Posts:

Sexiest WordPress Plugins: Online Backup for WordPress |

So, I first wrote about this topic on the wp-hackers list back in January 2009, explaining some of the scaling issues involved with having ambiguous rewrite rules and loads of static Pages in WordPress. A year later the same topic came up again in the WPTavern Forums, and later I wrote a blog post about the issue in more detail. That post generated lots of questions and responses.

In August 2011, thanks to highly valuable input from Andy Skelton which gave me a critical insight needed to make it work, and with Jon Cave and Mark Jaquith doing testing (read: breaking my patches over and over again), I was able to create a patch which fixed the problem (note: my final patch was slightly over-complicated, Jon Cave later patched it again to simplify some of the handling). This patch is now in WordPress 3.3.

So I figured I’d write up a quick post explaining the patch, how it works, and the subsequent consequences of it.

Now you have two problems.Quick Summary of the Problem

The original underlying problem is that WordPress relies on a set of rules to determine what type of page you’re looking for, and it uses only the URL itself to do this. Basically, given /some/url/like/this, WordPress has to figure out a) what you’re trying to see and b) how to query for that data from the database. The only information it has to help it do this is called the “rewrite rules”, which is basically a big list of regular expressions that turn the “pretty” URL into variables used for the main WP_Query system.

The user of the WordPress system has direct access to exactly one of these rewrite rules, which is the “Custom Structure” on the Settings->Permalink page. This custom string can be used to change what the “single post” URLs look like.

The problem is that certain custom structures will interfere with existing structures. If you make a custom structure that doesn’t start with something easily identifiable, like a number, then the default rewrite rules wouldn’t be able to cope with it.

To work around this problem, WordPress detected it and uses a flag called “verbose_rewrite_rules”, which triggers everything into changing the list of rules into more verbose ones, making the ambiguous rules into unambiguous ones. It did this by the simple method of making all Pages into static rules.

This works fine, but it doesn’t scale to large numbers of Pages. Once you have about 50-100 static Pages or so, and you’re using an ambiguous custom structure, then the system tends to fall apart. Most of the time, the ruleset grows too large to fit into a single mySQL query, meaning that the rules can no longer be properly saved in the database and must be rebuilt each time. The most obvious effect when this happens is that the number of queries on every page load rises from the below 50 range to 2000+ queries, and the site slows down to snail speed.

The “Fix”

The solution to this problem is deeper than simple optimizations. Remember that I said “WordPress relies on a set of rules to determine what type of page you’re looking for, and it uses only the URL itself to do this”. Well, to fix the problem, we have to give WordPress more input than just the URL. Specifically, we make it able to find out what Pages exist in the database.

When you use an ambiguous custom structure, WordPress 3.3 still detects that, and it still sets the verbose_page_rules flag. However, the flag now doesn’t cause the Pages to be made unambiguous in the rules. Instead, it changes the way the rules work. Specifically, it causes the following to happen:

  1. The Page rules now get put in front of the Post rules, and
  2. The actual matching process can do database queries to determine if the Page exists.

So now what happens is that the Page matching rules are run first, and for an ambiguous case, they’ll indeed match the Page rule. However, for all Page matches, a call to the get_page_by_path function is made, to see if that Page actually exists. If the Page doesn’t exist in the database, then the rule gets skipped even though it matched, and then the Post’s custom structure rules take over and will match the URL.

The Insight

The first patch I made while at WordCamp Montreal used this same approach of calling get_page_by_path, but the problem with it was that get_page_by_path was a rather expensive function to call at the time, especially for long page URLs. It was still better than what existed already, so I submitted the patch anyway, but it was less than ideal.

When I was at WordCamp San Francisco in August, hanging around all these awesome core developers, Andy Skelton commented on it and suggested a different kind of query. His suggestion didn’t actually work out directly, but it did give me the final idea which I implemented in get_page_by_path. Basically, Andy suggested splitting the URL path up into components and then querying for each one. I realized that you could split the path up by components, query for all of them at once, and then do a loop through the URL components in reverse order to determine if the URL referred to a Page that existed in the database or not.

So basically, given a URL like /aaa/bbb/ccc/ddd, get_page_by_path now does this:

SELECT ID, post_name, post_parent FROM $wpdb->posts WHERE post_name IN ('aaa','bbb','ccc','ddd') AND (post_type = 'page' OR post_type = 'attachment')

The results of this are stored in an array of objects using the ID as the array keys (a clever trick Andrew Nacin pointed out to me at the time).

By then looping through that array only once with a foreach, and comparing to the reversed form of the URL (ddd, ccc, bbb, aaa) you can make an algorithm that basically works like this:

foreach(results as res) {
  if (res->post_name = 'ddd') {
    get the parent of res from the results array
     (if it's not in the array, then it can't be the parent of ddd, which is ccc and should be in the array)
    check to make sure parent is 'ccc',
    loop back to get the parent of ccc and repeat the process until you run out of parents

This works because all the Pages in our /aaa/bbb/ccc/ddd hierarchy must be in the resulting array from that one query, if /aaa/bbb/ccc/ddd is a valid page. So you can quickly check, using that indexed ID key, to see if they are all there by working backwards. If they are all there, then you’ll eventually get to parent = zero (which is the root) and the post_name = ‘aaa’. If they’re not there, then the loop exits and you didn’t find the Page because it doesn’t actually exist.

So using this one query, you can check for the existence of a Page any number of levels deep fairly quickly and without lots of expensive database operations.


There are still some drawbacks though.

In theory, you could break this by making lots and lots of Pages, if you also made their hierarchy go hundreds of levels deep and thus make the loop operation take a long time. This seems unlikely to me, or at least way more unlikely than somebody making a mere couple hundreds of Pages. Also, WordPress won’t let you use the same Page name twice on the same level, so you’d really have to try for it to make this take too long.

If you try to make a URL longer than around 900K or so, the query will break. Pretty sure it’d break before that though, and anyway most people can’t remember URLs with the contents of a whole book in them. ;)

This also adds one SQL operation to every single Post page lookup. However, this is still better than having it break and try to run a few thousand queries every time in order to build rewrite rules which it can’t ultimately save. And the SQL being used is relatively fast, since post_name and post_type are both indexed fields.

Basically, for the very few and specific cases that had the problem, the speedup is dramatic and immediate. For the cases that use unambiguous rules, nothing has changed at all.

There’s still some bits that need to be fixed. Some of the code is duplicated in a couple of places and that needs to be merged. The pagename rewrite rule is a bit of a hack to avoid clashing, but it works everywhere even if it does make the regexp purist groan with dismay (for critics of this, please know that I did indeed try to do this using a regexp comment to make the difference instead of the strange and silly expression, but it doesn’t work because the regexp needs to be in a PHP array key).

Anyway, there you have it. I wrote the patch, but at least 5 other core developers contributed ideas and put in the grunt work in testing the result. A lot of brain power from these guys went into what is such a small little thing, really. A bit obscure, but I figured some people might like to read about it. :)


This site is for a Hamilton-based town-planning consultancy.

It is built on the WordPress platform, using a theme custom-coded by Urban Legend web based on designs from Cube Media.

It uses a left-side horizontal menu customised with jQuery, and links section at page bottom controlled by customised widgets.

This site is for a NZ-government agency, FEUT, which manages carbon emissions for government-owned forests.

The site design is by McGovern & Associates, and coded into a custom WordPress theme by Urban Legend web.

The site is coded in HTML5, and features some custom jQuery in the Licensed Crown Forests section, and on the contact page. It also gives its owners the ability to update a forests database from an uploaded Excel file using a customised WordPress plugin.

It uses modern @Font-face coding to render the desired font family across platforms.

Wrote this quick WordPress code snippet at WordCamp Louisville. It makes a /random/ URL on your site which redirects to a random post. Thought some people might find it useful.

Not a perfect little snippet, but gets the job done. Note the use of the little-used 307 redirect for temporary redirection. This is to make browsers not cache the results of the redirect, like some of them might do with a 302.

function random_add_rewrite() {
       global $wp;
       add_rewrite_rule('random/?$', 'index.php?random=1', 'top');

function random_template() {
       if (get_query_var('random') == 1) {
               $posts = get_posts('post_type=post&orderby=rand&numberposts=1');
               foreach($posts as $post) {
                       $link = get_permalink($post);

There’s plugins that do this sort of thing too, but this is such a simple little thing that it doesn’t really need a big amount of code to do.

Edit: Added get_permalink() optimization from @Raherian.

If you read “how-to” stuff for WordPress sites around the web, then you frequently run across what many people like to call “snippets”. Short bits of code or functions to do various things. I myself post snippets frequently, usually made up on the fly to solve somebody’s specific problem.

One question I get a fair amount is “where do I add this code?”

The usual answer to this for a lot of people is “in the theme’s functions.php file”. This is a quick solution, but it is often a problematic one.

The reason this has become the more or less go-to place to add these snippets is because it’s complicated to explain to a newbie how to make a plugin and activate it, or to point out the problems with modifying core code, or plugin code. Saying to look for a specific file in their theme, on the other hand, is quick and easy, and until recently theme upgrades have been fairly rare.

However, as themes get upgrades, it becomes more and more incorrect to tell people to modify them directly. And telling people how to create child themes is complex, even if it’s easy to do.

So I’d like to start a new trend, and recommend that people start making Site-Specific Plugins. Most people who run WP sites on a serious level do this in some way already, but if you make it sorta-standard practice, then it’ll make things simpler all around.

How to create a Site-Specific Plugin

1. Create a new directory in the plugins directory. Name it after the site in some fashion. For example, /wp-content/plugins/ or something like that.

2. Create a new php file in that directory. Name is dealer’s choice.

3. Put this in the file:

Plugin Name: Site Plugin for
Description: Site specific code changes for

4. Finally, go activate your new blank plugin on the site.

Now you have a simple and specific place to add snippets. It will survive upgrades of any sort, and you can edit it to add new code on an as needed basis. What’s more, it’s kinda sorta break-proof. If the user uses the built-in plugin editor to edit it, and they add code that breaks the site, then the editor detects that on saving the code and deactivates the plugin, preventing the “white screen of death” for their site.

This is a much better way to use “snippets” than the theme’s functions.php file, and we should really use it more often in our replies to users.

The Parrot PlaceThe Parrot place is an online pet shop, offering pet supplies, fish food, and specialising in supplies for birds.

It is WordPress-driven, and uses the E-commerce plugin for online sales.

Urban Legend web was contracted to create the collapsible menus on the left side of the site, and to make changes to the backend of the E-commerce plugin to clarify the display of categories. We also helped with some minor styling tweaks to the main menus.

Marblehead GalleryMarble Head Galley is a restaurant in Marblehead, Ohio, USA.

Urban Legend web was contracted to provide a calendar application which let the site owners enter daily dinner specials by month. We used an existing WordPress plugin, calendar, and incorporated it into the slider mechanism used on the front page of the site.

We customised the calendar plugin so that the current week’s specials only were shown, with a link to the full calendar month.  We helped to style the calendar, but weren’t involved in the design of the site itself.

Google rolled out their +1 button today. So I added it here. You’ll find it below all the posts. Try it out.

Here’s the simple-stupid plugin I wrote to do it. While you can just edit your theme, I like making these sort of things into plugins. That way, I can turn them off at will, and I know exactly where to go to change them without having to dive into my theme code. Also, if I change themes, the code still works on the new theme.

Plugin Name: Otto's Google +1 Button
Description: Add a +1 button after the content.
Author: Otto
Version: 999

add_filter('the_content', 'google_plusone');

function google_plusone($content) {
	$content = $content.'<div class="plusone"><g:plusone size="tall" href="'.get_permalink().'"></g:plusone></div>';
	return $content;

add_action ('wp_enqueue_scripts','google_plusone_script');

function google_plusone_script() {
	wp_enqueue_script('google-plusone', '', array(), null);

I wrapped the button in a div so that I could style it. In my particular case, I’m floating it right and giving it a margin, same as the Twitter and Facebook plugins. One day, I’ll make all these little Google plugins more generic and configurable, and roll them into a Simple Google Connect plugin. :)

One thing I don’t like is that the +1 button only works for people who are logged into a GMail account. Sorry Google Apps users, you’re out of luck. Complain to Google until they fix it.

If you want to add more parameters to the plugin and reconfigure it, you can find out about the available parameters here: