Sanitizing text field and text area

Heya Guido!

In my experience those functions do not alter double quotes and apostrophes/single quotes. The ampersand is changed to a HTML entity by wp_kses_post(), but not sanitize_text_field(). Not that this changes your question. The scope of application might be more limited than you thought. Or there may be additional filtering going on due to your theme or other plugins on your dev/test site.

Doesn’t look nice in form submissions because they are plain text?

There is no filter that I’m aware of that allows certain common characters through without converting to HTML entities. However, there is a global array of HTML entity names that are permitted: $allowedentitynames If you were to remove entities you don’t want converted, it might meet your needs. I’ve not tested this myself. It would be a good idea to restore the original entities when you are done since other code may be relying upon this list for other purposes.

My inclination is to use “pre_kses” and “sanitize_text_field” filters to seek out undesirable entities and restore the respective characters. Or run the entire thing through html_entity_decode() to wholesale restore all characters. While it may seem inefficient to run through kses or similar only to undo the conversions afterwards, there are other benefits from kses that are good to implement in sanitizing text.

Of course the other option is to write your own sanitation function that does much of what kses does except for encoding certain characters. There are a number of WP functions you could still use to some benefit that do not do entity conversions, wp_check_invalid_utf8() for example. Thus you don’t have to totally code your own sanitation function from the ground up. Just be sure to call the right functions from within your sanitation function.

It’s normal for form data coming into PHP via $_POST to be slashed. You simply run data through stripslashes(). If you are placing form data into a plain text email, you don’t need much sanitation since code injection attacks aren’t possible in plain text. It would be a good idea to run data through strip_tags() just in case the user added HTML tags, which have no place in plain text.

For data destined for the DB, the data does need to be slashed again, but it’s a good idea to first stripslashes() to ensure you are starting from an unslashed state. You do not want to accidentally double slash data. In any case, if using WP functions to add data to the DB, the slashing is either handled for you or is added as part of $wpdb->prepare().

If the data is destined for a web page or HTML email, there is no problem with the entities conversion. In fact, you need to run data at least through htmlspecialchars(), which converts ampersands, quotes, apostrophes, and less than signs to entities. This is necessary to prevent code injection attacks. Because entities display correctly as characters in HTML, there should be no problem with entity conversions.

What sanitation you do is dependent upon the destination of the data. At least do stripslashes() on incoming form data. Do more as required by the destination. Further validation may be warranted, depending on the nature of the data asked for. For example, if a quantity count is expected, only characters 0-9 need be allowed, which would never be slashed. An exception to the do stripslashes() on everything rule, though no harm would come by doing stripslashes() anyway.