When reflecting timestamp columns in MySQL current_timestamp comes back
as the default value. This causes insertion errors later on as
'current_timestamp' is an invalid value for timestamp columns.
Refs #4184
Abstracts the `require_once` of the schema file so it can be done twice. The added second call is a fallback for the previous APP_DIR-based naming to provide backwards compatibility.
Removes now-obsolete CakeSchema tests that involved `Configure::read('App.dir')`. The CakeSchema::name is now always static (and predictable) in the default case.
When conditions are empty we can assume one of two things:
* The person made a mistake.
* The person is doing the join conditions in the where clause.
In both cases we should attempt to generate proper SQL.
Fixes#4189
Eg:
Actual Posted URL:
/admin/settings/settings/prefix/Access%20Control
$_GET value:
/admin/settings/settings/prefix/Access_Control
Since $unsetUrl differs, the $_GET value will get copied in to
CakeRequest::$query, causing CakeRequest::here() to return:
/admin/settings/settings/prefix/Access%20Control?%2Fadmin%2Fsettings%2Fsettings%2Fprefix%2FAccess_Control=
This confuses SecurityComponent in the following line:
f23d811ff5/lib/Cake/Controller/Component/SecurityComponent.php (L514)
Instead of turning on/off strict mode based on the user supplied input,
cast everything to strings and always use a strict check. This avoids
the potential issue of a bad user using hexadecimal when they should not
be allowed to do so. Thanks to 'Kurita Takashi' for pointing this out.
While filter_var() allows a number of email addresses that
Validation::email() does not, it misses out of email address that
contain IDN host names, and unicode mailboxes. Both of these are
generally deliverable, and should be permitted. filter_var() also fails
on local mailboxes like `root@localhost` which is useful in the context
of cron jobs.
Fixes#3742
From php.net/exception.getcode
> Returns the exception code as integer in Exception but possibly as other type in Exception descendants (for example as string in PDOException).
Historically [prop=1] has matched prop=true as well. This restores that
and also fixes [prop=0] not finding falsey values.
This makes the typing less strict in Hash::extract() but I don't think
it is unreasonable given PHP's type juggling.
Refs #3288
