About the Author

Chris Shiflett

Hi, I’m Chris: entrepreneur, community leader, husband, and father. I live and work in Boulder, CO.

Zend_Filter Reviewed on SitePoint

Maarten Manders graciously took the time to review the Zend_Filter component of the Zend Framework. I think criticism and public discussion are healthy. Unfortunately, I don't have time to offer a very detailed response, but I'll try to remedy that with a followup post later in the week.

One thing worth noting is that Zend_Filter was extracted from Zend_InputFilter shortly before the preview release. Because it provides such a rigid approach to input filtering, some contributors pointed out that Zend_InputFilter does not provide enough flexibility for simple cases such as filtering an argument passed to a method. (Discussions have taken place on the mailing list about whether such granular error checking is beneficial.) To remedy this, I decided to separate the filtering methods from the input filtering framework that uses them.

Zend_Filter is far from impressive, in my opinion, because it's simply a library of static methods for filtering data. (I do think the naming convention is more consistent than alternatives.) Combined with Zend_InputFilter, however, it offers a much more structured approach to input filtering, and I think it's a big step in the right direction toward more secure PHP programming.

I should really explain Zend_InputFilter in more detail, but since I'm pressed for time, here are some quick responses to Maarten's specific comments:

  • isGreaterThan() and isLessThan() are superfluous now.
  • I'd love to see some suggestions (in the form of use cases) for a friendlier isDate(). :-)
  • I'm not sure who wrote isHostname(), but refactoring it is near the top of my TODO list.
  • Concerning the name for isRegex(), the is prefix is important for reasons of consistency, so perhaps isMatch()?
  • isName() is a candidate for removal.
  • isPhone() only supports US numbers, because it's a stub. This is one of the few methods where internationalization is going to affect the requirements substantially from one country to the next. It also brings up the question of where to draw the line.
  • I have considered adding some escaping methods to Zend_Filter and Zend_InputFilter, but I hate to erode the distinction between filtering and escaping. I have much more to say about this, but it will have to wait.

I'd like to thank Maarten for taking the time to compose his thoughts and impressions, and I'd also like to thank everyone who has done the same on the mailing lists.

About this post

Zend_Filter Reviewed on SitePoint was posted on Tue, 28 Mar 2006. If you liked it, follow me on Twitter or share:


1.Mathieu Kooiman said:

Regarding isRegex() vs isMatch().. How about simply: matches(). It fits in the naming convention and doesn't look out of place, like isMatch().

Wed, 29 Mar 2006 at 06:47:10 GMT Link

2.Rob Allen said:

I'd like to see either Zend_InputFilter::isset() or the getXXX functions to accept a default to use if the key isn't in the array.

Wed, 29 Mar 2006 at 13:11:12 GMT Link

3.Chris Shiflett said:

Hi Mathieu,

The name matches() doesn't adhere to the naming convention at all. I think isMatches() might be the best candidate.

Wed, 29 Mar 2006 at 13:25:52 GMT Link

4.Chris Shiflett said:

Or, perhaps just isMatch(), so it doesn't sound like a grammatical error. :-)

Wed, 29 Mar 2006 at 13:26:44 GMT Link

5.Chris Shiflett said:

Rob, you're right. I like the option to have a default value. I really need to create a TODO list in the repository:

1. Filtering arrays - I've got two patches from other contributors that I need to examine.

2. Default values

3. Refactoring isHostname()

There are probably other things...

Wed, 29 Mar 2006 at 13:30:09 GMT Link

6.Mike Willbanks said:

What I find irritating about the Filter and Input Filter is it is basically juist encapsulating previous functions from PHP's methods and a few bundled regular expressions.

Where as different methodologies it could look something to the effect of HTML_QuickForms in how the validation takes place, which in my opinion has a very nice way to declair what is optional / required and handle all of the operations that are needed for the input. And if not you can write other rules.

It just seems to take much longer to use the Zend_Filter or Zend_Input_Filter to do something that is the equivelent of strip_tags() ($filter->noTags()). Is there a plan on adding more support for higher validation such as a multi-array?

Say you have an array $a I would normallly do this differently but since its harder to read on a blog I did it the alternative way:

$a = array();

$a[n] = array('name' => 'Name', 'url' => 'URL');

n meaning a numberic index.

Now my thought would be an array explaining the structure and the ruleset to the Zend_Filter and/or Zend_Input_Filter:

$valid = array();

$valid['numeric'] = array('name' => 'string', 'url' => 'url');

So in essense saying that each inital key must be numeric, the name must be a string and the url must be a url (basically allowing for a custom type that is a url regular expression or validation routine). I know that this isn't exactly the cleanest example as more thought goes in for the additional complexity and how to handle the validation but I think you get the idea ;)

Wed, 29 Mar 2006 at 14:06:03 GMT Link

7.Chris Shiflett said:

Hi Mike,

There is a subtle but important reason for encapsulating the various filtering approaches into a single library: consistency. Zend_Filter offers a simple naming convention that promotes code clarity and makes it easier to intuit the behavior of a particular method.

The reason for methods such as noTags() is not only to provide this consistency, but also because it's necessary for retrieving data from the Zend_InputFilter cage. This is something I want to explain in more detail later.

> Is there a plan on adding more support for higher

> validation such as a multi-array?

Absolutely. Handling arrays is something I want to be sure we do right, but it's a necessity.

Concerning your comments about mapping filtering methods to form data, that is also on the TODO list (and thanks for reminding me). Currently, Zend_InputFilter is more about control and security than anything else.

I like your suggestion as a way to map filtering methods to form data.

Wed, 29 Mar 2006 at 15:13:55 GMT Link

8.Arnaud said:

On a side note what are the plans for the ZForm ? It requires a non-existent ZRequest class and is pretty hard to get an idea of how it is going to work :)

Wed, 29 Mar 2006 at 15:22:43 GMT Link

9.Chris Shiflett said:

That's a good question, Arnaud. When I first saw the Zend_Form component, I assumed it would be something similiar in spirit to HTML_QuickForm. From my quick glances through the code, it seems to be more about generating forms and fancy Ajax stuff than form processing.

There have been mentions of renaming the current component, so that Zend_Form would be more along the lines of what people expect it to be. This would also be a perfect place to integrate Zend_InputFilter, so that processing forms is as simple as Mike's example.

I also want to point out two approaches for the mapping, both of which are under consideration:

1. Use PHP code. An example is the array Mike mentions.

2. Use convention. For example, perhaps a naming convention dictates what filtering methods to use.

The second option will raise eyebrows, because it seems like the client gets to decide what filtering is to be used, but that's not really the case. Again, this is something else I'd like to explain in more detail. :-)

I've got to catch a flight, but I'll try to elaborate on all of these topics in a separate blog post. Thanks very much for the feedback and discussion.

Wed, 29 Mar 2006 at 15:29:30 GMT Link

10.Arnaud said:

It would be extremely helpful as it would leave developers to focus on the form display and configuration. Quickform gives most of that but, as many others, I like to try new things :-)

On the mapping subject though I tend to like conventions I can't help feeling it introduces some 'magic', as in 'where-the-heck-does-this-comes-from'. If everything is built around that principle (RoR) the initial cost of figuring it out is alleviated in the long run. Therefore, a php mapping array would be a good approach. Solar_Form has good ideas on how to do form related work.

Wed, 29 Mar 2006 at 16:07:18 GMT Link

11.Richard said:

Simon Willison has an interesting approach:


Wed, 29 Mar 2006 at 16:15:13 GMT Link

12.Paul Reinheimer said:

I'm happy with your choice to stick to validating, rather than moving into escaping as well.

At present, I feel the methods involved in escaping data are pretty well understood, *_escape_string(), *_real_escape_string(), htmlentities() and such. It's validating data that I need help with :).

The only advantage I can see to moving some level of escaping into the framework is in terms of keeping up to new threats as they are discovered. Since presumably, updating the zend framework will be easier than finding my own use of the apropriate escaping functions in all my code. I could however replicate that functionality myself by using a single library for all my projects.

Wed, 29 Mar 2006 at 17:26:32 GMT Link

13.Rob Allen said:

Escaping at the input filter side would be a nightmare.

I'd like to see Zend_View escape by default though so that additional effort was required for the times that you don't want the data escaped, rather than the other way around.

No idea how to do though :)

Wed, 29 Mar 2006 at 18:52:58 GMT Link

14.Arnaud said:

Rob: you can write a helper for Zend_View that does the escaping and output for you. Something along the lines of Savant with $this->eprint()

Wed, 29 Mar 2006 at 19:07:03 GMT Link

15.Rob Allen said:


That's the problem: you have to remember to use the eprint() function. If you forget and use echo or print or whatever, it all still works; except that you have a possible security issue.

So far this is the only advantage to smarty that I've found. In Smarty you can set it up so that the default display a variable construct of {$var} will automatically escape and if you need a variabled not escaped you have to use {$var|smarty:nodefaults}. I quite like this idea as the simplest way to output a variable is automatically safe.

Thu, 30 Mar 2006 at 08:17:18 GMT Link

16.Arnaud said:

Rob: indeed, the problem is that since templates are plain php you can do what you want. I think that you need to be rigourous when coding anyway.

You would need to use something like smarty or html_template_flexy to have automatic output escaping. I used smarty for a while but now i'm thinking that having php templates is pretty nice as it gieves a lot of power and you just need that extra bit of carefulness which you can easily get using pair-programming and code reviews.

Thu, 30 Mar 2006 at 08:43:34 GMT Link

17.Lee said:

I like some of the components in the framework and I agree that Zend_Filter and Zend_InputFilter are a step in the right direction when it comes to securing PHP applications, although they do need some work.

One thing I would like to ask the group of commenters including you Chris is:

If you were a new programmer, or starting a brand new php project, would you use the Zend Framework? Is this framework going to become the standard? or should we stick with what we use?

I'm all for standardizing a framework, but is this it?

Thu, 30 Mar 2006 at 18:59:38 GMT Link

18.Mike Willbanks said:


If you are just starting a new project and it is going to take a long time it might be benifical. Right now I am just playing with certain peices of the framework because I feel other ones are very likely to change and might end up being more maintainence in the long run.

I would look and read the documentation and see what the piece adds. As for the Zend_Filter and Zend_InputFilter I think there is a lot of work to be done. It seems only baseline functionality exists as I previously noted.

One thing I have been personally looking into for a while is how I want an input filter to work and I might just extend the zend framework to allow for my liking of it, so that is always a good option.

I guess I kind of talked around the point but just beware that the Zend Framework isn't quite primetime material yet.

Sat, 01 Apr 2006 at 00:26:47 GMT Link

19.Prasanna said:


Do you have any comments on zend_search?

Do you have a seperate thread for it?


Mon, 17 Apr 2006 at 22:01:32 GMT Link

Hello! What’s your name?

Want to comment? Please connect with Twitter to join the discussion.