Surprising WP Fact #2

Although I didn’t realise at the time that it was going to look like the start of a theme, my last post turns out to be #1 in a series of Surprising Facts. I’m hoping #2, i.e. this one, will be the last.

This Surprising Fact concerns WordPress. I don’t think it quite classes as a bug, as it’s probably quite reasonable in some obscure way — but it ought at least to be documented (somewhere other than in this blog, I mean).

I haven’t been working with WordPress for very long (perhaps you can tell!), and it took me some time before I realised that by default WordPress blocks all posted variables but provides a way for you to allow those with specific names. You use the ‘query_vars’ hook and simply list the names of the variables you want to post or use in a query string.

function my_query_vars_filter( $vars )
{
    //...
    $vars[] = 'some_variable';
    $vars[] = 'another';

    return $vars;
}

add_filter( 'query_vars', 'my_query_vars_filter' );

You can now post some_variable or another from a form or in a URL:

http://mysite.com/?p=123&some_variable=42&another=43

This is a useful technique for communicating to a page that it needs to display a message, such as an error message. Suppose we have a sign-up page where a visitor can enter a name and email address before proceeding to the next page. Clearly we need to validate the input — particularly the email address — before going any further. If the validation fails we might re-call the same page, but with a flag in the query string telling it to display an error message. Something like:

http://mysite.com/?p=123&error=invalid_email

Of course, we’ll have to add ‘error’ to the ‘query_vars’ list:

function my_query_vars_filter( $vars )
{
    // ...
    $vars[] = 'error';

    return $vars;
}

But curiously, when I did this it didn’t work. Everything else in the query string was readable by the target script, but there was no $error variable.

After much head-scratching it occurred to me that the choice of variable identifier could be the cause of the problem. There are all sorts of conceivable reasons why WordPress might want to block the use of an $error variable. For one thing, it could conflict with WordPress’s use of the variable for a similar purpose. And there might be security issues.

To test this theory I simply changed the identifier to $something_error and changed ‘error’ to ‘something_error’ in the query_vars filter. But it still didn’t work.

Could it be then, I asked myself, that WordPress blocks anything that includes the word ‘error’? Though hardly plausible this would seem to be the case. Keeping the rest of the logic as it stood, I changed ‘something_error’ to just ‘something’ and it all came back to life.

I suppose I should really hunt through the WordPress code and try to find where this is happening. Programs are supposed to be determinate things after all, and an empirical approach feels somehow less than satisfactory, but I don’t have the time, I’m afraid. If anyone else can throw any light on the situation, please !