I just read this thread and i had a led moment, ecology before everything

Why not open the second parameter to other input altering methods/functions, now you can only xss clean the input.

So if you want to xss clean it you would have to do

But then you also can add other functions like

It’s not a big change but i think it could benefit some developers.

That is a good idea
And it should be fairly easy to implement while maintaining backwards compatability, as you just check is it’s a bool, in which case you process it as it currently is, otherwise, it’s a string, so call each function in turn, like with the validation class

Edit: Just thought of a potential problem
What if you have global XSS cleaning enabled, but you have a particular post value you don’t want cleaned? Normally you could just pass in false (I’m assuming that would currently override the global?). Any ideas how to get around this if you don’t want xss_clean, but do wat some other calls, such as trim etc

You could keep the 2nd param as a bool for xss_clean and make the feature request the 3rd param

-or-

Add an option that would turn xss_clean off, such as

If the global cleaning is enabled it kicks in as soon as the input class is loaded so the method as it is doesn’t overwrite the global cleaning either. It’s a change I requested a while ago.

They could keep the boolean but i think the preferred way should be to add the method/function name because it’s easier to know what the parameter does then.

simshaun your ideas add too much crud to the method. The second parameter already is input altering and if you call the method without the second parameter it won’t clean the value. Adding xss_clean_off will make the method more complex as it is a switch instead of a function.

Hell.. I was just throwing ideas out there, not trying to crud the method up. I dont know and haven’t even looked at how the form_validation lib handles the rules.