Overview of merged pull requests
include the overseen options:
mark the legacy options as @deprecated and show alternative
BUGFIX: Use custom error view for rendering group independent of the configuration ‘templatePathAndFilename’
previously, a custom error view is for rendering groups only used if
templatePathAndFilename is set. * See: #1108
A custom view will now be used if …
- … there is a matching rendering group (no further checks. It could be also a rendering group with empty options (no viewClassName or viewOptions) … what would then trow an error probably - depending on the view)
defaultRenderingOptions.templatePathAndFilename passes isset() (to not change previous working behaviour - should get depreceated sometime)
[x] Code follows the PSR-2 coding style
[x] Tests have been created, run and adjusted as needed
[x] The PR is created against the lowest maintained branch
Makes sure the check does not use potentially outdated information.
When resolving values for a route via DynamicRoutePart, object are only being looked up in the persistence manager.
With this change, we honour if a identifier is found, and if not, we look at the object to see, if it has a __toString method available, to give us a value.
This is backward compatible, since we respect the identifier, if given at first
When HMAC validation fails during request processing, the controller will return a response with a status code of 400, as that is caused by a bad request. The exception is logged with a notice to the log, to aid in debugging errors
Previously the uncaught exception would cause a status 500 response and log a critical error.
This clarifies the use of