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
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
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
When the disabled attribute is just array(1), then the attribute should
be filtered out of select element attributes. This is kind of a hacky
workaround but changing the underlying attribute handling is going to be
pretty tricky and far more dangerous.
Fixes#3546
When sending multi-part emails with no attachments we shouldn't include
the outer multipart/mixed header as it confuses Outlook and causes it to
show the email as having attachments even though there are none.
A bunch of tests need to be adjusted as the empty multipart/mixed
container has been removed.
Fixes#3474
Because count() queries don't happen in many cases now, the lastQueries
index needs to shift up by one because a query isn't happening anymore.
Refs #3333
While including the entire protocol, host, port, path and query would be
even better in theory, it gets complicated when proxies and load
balancers are involved.
Fixes#3442
By including the URL in generated hash for secured forms we prevent
a class of abuse where a user uses one secured form to post into a
controller action the form was not originally intended for. These cross
action requests could potentially violate developer's mental model of
how SecurityComponent works and produce unexpected/undesirable outcomes.
Thanks to Kurita Takashi for pointing this issue out, and suggesting
a fix.
