There's a small concern here I didn't think about before (not trying to block this in case someone gets that impression). In our bootstrap, we define the error handler for JError::raiseError() to ultimately call JError::customErrorPage() which renders the page as a JDocumentError instance (what we're trying to avoid here). One of the things JDocumentError::render() does is set the response headers with the correct 403 HTTP code. That needs to be accounted for IMO if we are going to move away from rendering an error document, otherwise you're going to have error pages go from returning a 403 code to a 200 code which is incorrect for that context.
raiseWarning doesn't change the response headers either. So there's really two options:
1) Leave raiseError calls as is, like I mentioned before JDocumentError just sucks when it comes to adding extra bells and whistles.
2) Set the response header ($app->setHeader()) the same way JDocumentError::render() does in the controller. You avoid the error page and still set the right HTTP code.
2) Set the response header ($app->setHeader()) the same way JDocumentError::render() does in the controller. You avoid the error page and still set the right HTTP code.
That's over my head I am afraid. Better close this and let it to someone more qualified.
Could you look also at #7825 where the matter is slightly different?
There's a small concern here I didn't think about before (not trying to block this in case someone gets that impression). In our bootstrap, we define the error handler for JError::raiseError() to ultimately call JError::customErrorPage() which renders the page as a
JDocumentError
instance (what we're trying to avoid here). One of the things JDocumentError::render() does is set the response headers with the correct 403 HTTP code. That needs to be accounted for IMO if we are going to move away from rendering an error document, otherwise you're going to have error pages go from returning a 403 code to a 200 code which is incorrect for that context.