WordPress Data Validation for Dummies (Part One)

If you develop plugins or themes, chances are you’ve wanted to create some sort of options page. Or maybe even a custom meta box for posts that take additional information and uses it somewhere on the site.

When you start letting a users input anything, you step into the danger zone. Why? Because you can’t trust the user, even if that user is you. If a user can enter something at any point that will break the site (think cross site scripting or something worse), chances are they will. Even the best WordPress plugins and themes are guilty of shoddy data validation practices. Fortunatley, it’s not that hard to do it right.

The first step on your data validation highway should always be checking intent. In psuedo code this might like something like…

[code]
Did the user mean to have this happen?
If not, bail, return out of the function
If so, continue
[/code]

WordPress provides a convenient way to check intention called a nonce (number used once). A nonce is a random number specific to a user and only valid for 24 hours. If you use the settings API to creating theme or plugin options pages, WordPress takes care of nonces for you.

If you’re creating a custom meta box or not using the settings API, that’s not the case. You have to manually insert a nonce field. Fortunately, WordPress provides a handy function for this.

PHP

1

2

3

4

5

6

wp_nonce_field() echos out a hidden input field with the name specified by the second argument (field_name in our example). The first argument is the action. You use this to verify the nonce later. Assuming we’re creating a meta box, we’d hook into ‘save_post’. The intention we’re checking to making sure that user is actually on the edit post screen. Only if she is, will our save function continue on its way:

PHP

1

2

3

4

5

6

7

8

Why check for this? Because this action, ‘save_post’ is found inside the wp_insert_post() function, which can be called anywhere in the WordPress environment. If another plugin or something else were to call this function, our action, if it lacked the verifying intention step, would fire. This could cause a bunch of fun PHP warnings and errors. No good.

WordPress has the ability to be a full featured membership site or multiple author site. To divide up all those users, WordPress uses roles and capabilities. Capabilities are what we’re concerned about here. To go back to our psuedo code example:

[code]
Is the user allowed to do this?
If not, bail, return out of the function.
If so, continue
[/code]

Yet another handy WordPress function to the rescue: current_user_can(). Its one argument is the name of the capability you’d like to check. To go back to our meta box example, we want to make sure the current user, the one doing the editing, is allowed to edit the post:

PHP

1

2

3

4

5

6

7

8

9

10

Checking permissions should come after intent because permissions are irrelevant without intent.

This is only the tip of the WordPress data validation iceberg. Subsequent articles in this series will cover sterilizing and verifying data before echoing it to the screen or storing it in the WordPress database.