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
Changed `Element.beforeRender` and `Element.afterRender` back to
`View.beforeRender` and `View.afterRender` Also added a getter for
`View::_currentType`.
Added more tests to make sure that things were getting reset right
And also that View::render and View::element events were working
As expected
Changed Event names back, added view type getter
Changed `Element.beforeRender` and `Element.afterRender` back to
`View.beforeRender` and `View.afterRender` Also added a getter and
setter for `View::_currentType`.
Added more tests to make sure that things were getting reset right
And also that View::render and View::element events were working
As expected
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).
And also made it so when the event fires the subjects type is
`View::TYPE_ELEMENT`. Wrote some tests which I hope are done right I
don't really know the bes way to write a test for a event listener
This has the benefit that the realpath() method is not applied to a
registered stream wrapper in the constructor of the Folder class.
Using the realpath() method will break the stream.
Thank "davalb" for the original patch.
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
Unrelated to this bug, I added a "head" function inside of HttpSocket to go along with the GET/POST/PUT/DELETE/PATCH combination that's already present. Came in handy for me for deciding if I wanted to hit a resource with HttpSocket or not.