> First, let me state that neither myself or *anyone* on the CakePHP
> core team gets their jollies from closing tickets as 'wontfix' or
> 'invalid'. We all appreciate the time & effort that is spent in
> writing a ticket, and are grateful that people are attempting to make
> CakePHP a better framework.

> Alright, I'm going to take the time to explain the reasoning behind
> the 'wontfix' tag that was attributed to tickethttps://trac.cakephp.org/ticket/5145
> and perhaps offer some insight in the thought processes that go on
> behind the scenes that are not usually explained, for the simple
> reason that writing a small novella for each ticket would consume all
> the free time that any of us has.

> First, you must note that CakePHP is an ''opinionated'' framework; we
> enforce certain conventions and (what we consider to be) best
> practices. This also translates to any code that is included in the
> core; if we believe that certain enhancements/features would go
> against accepted best-practices of development, then it has no place
> in the official codebase. Being conscious of the limitations of the
> real world, however, we have endeavoured to allow users of the
> framework to customize & extend the base functionality to accommodate
> a wide variety of edge case uses, an example of which is the topic of
> this ticket: Validation rules. The rules that are provided in the core
> are present for one of two reasons: 1) the rule is quite common and
> used in many different applications (e.g. notEmpty, numeric) or 2) the
> implementation of the rule is quite complex, and we feel it best to
> provide that functionality so that people need not re-invent the wheel
> (e.g. credit cards, date and time). The alphanumeric+ whitespace
> +whitelist_of_valid_characters rule which you have proposed does not
> fall within either of the above two categories.

> It is not a rule which many people require, simply because if you are
> allowing non alphanumeric characters, you need to either provide a
> whitelist or a blacklist of additional characters. Neither of these
> options is maintainable in the long-term; you will be eternally adding
> characters to your (white|black)list to comply with varying & changing
> requirements from your application.

> However, I do understand that the real-world sometimes does not
> coincide with the ivory tower that comprises best practices of
> software design & implementation patterns. This is where the
> extensibility of the framework comes into play. The above validation
> rule that you both desire can be very easily implemented in a variety
> of places: 1) in a model, for domain-specific validation that need not
> be available to the rest of your application. 2) at the AppModel
> level, so that all your models in a given application may use it. 3)
> In a behavior, so that you can pick & choose which models will have
> the custom validation rules available to them. In addition, this also
> allows you to make the rules portable; you could even package it up in
> a plugin along with some test cases, thus utilizing the full extent of
> CakePHP's extensibility.

> Furthermore, every line of code that is added to the CakePHP codebase
> is a line of code that the core team needs to maintain. What might
> seem like a simple validation rule addition actually encompasses the
> validation rule itself, a new test case with at least a dozen new
> assertions, possible modification of bake templates for models to
> include the new validation rule, integration tests for the new
> validation rule and its interaction with the FormHelper, in addition
> to whatever new functionality gets added in future versions. As a
> result, what seems like a simple addition of a few lines of code
> snowballs into several hundred lines and countless hours of work. Thus
> you can imagine why we shy away from adding new 'features' that
> introduce infinitesimally new functionality, especially when such
> functionality is actually best implemented with your own application
> logic in mind. This is not to say that we never plan on adding new and
> awesome things to CakePHP; you need only visit the development branch
> for 1.3 onhttp://thechaw.com/cakephp/source/branches/1.3to see for
> yourself.

> Given all that I've said, however, I still realize that sometimes
> certain problems need dirty solutions. To this end, I've written a
> simple example of how you would create an alphanumeric
> +whitelist_of_valid_characters rule:

> // in either your app_model.php or a model class
>     public function alnumWhitelist($data, $whitelist = array()) {
>         $data = array_values($data);
>         $check = $data[0];
>         $whitelist = implode($whitelist);
>         $rule = "/^[\p{Ll}\p{Lm}\p{Lo}\p{Lt}\p{Lu}\p{Nd}{$whitelist}]+
> $/mu";

>         return preg_match($rule, $check);
>     }

> // in your model validation rules
>  public $validate = array(
>         'name' => array(
>             'rule' => array('alnumWhitelist', array('\s', '\-', "\'",
> '\"')),
>             'allowEmpty' => false
>         ),
>     );

> So please, try and remember that we're not trying to be the bad guys.
> The whole core team has nothing but the best intentions for CakePHP
> and the community behind it. When we mark tickets as invalid or
> wontfix, we're not trying to piss you off. Every decision has a
> reason, and many of them are debated extensively among the core team.

> Thanks, and have a pleasant day.