Displaying Error Messages From Laravel Running on Microsoft IIS
Error messages are crucial to debugging during development, but what happens when they don't show up like they're supposed to? Have a look at a possible fix if you're running the Laravel PHP framework on IIS.
Join the DZone community and get the full member experience.Join For Free
The debate rages on amongst the zealots: "If I need to run PHP and I'm absolutely forced to use Windows to host my web server, do I use IIS or just go right to Apache, or even Nginx?"
This article will not even begin to broach that subject as the space for this post has to be kept well under what would be afforded Tolstoy.
However, since PHP frameworks are becoming lighter as well as increasingly flexible, these solutions are fast becoming desirable on any platform. Like it or lump it, we will likely, at some point in our careers, have to install one or more PHP frameworks onto a Windows server running IIS.
Getting to the point of this article, I recently had occasion to install the Laravel PHP Framework onto a Windows server running IIS 7.x (not the most recent, I know, but those were the requirements).
So after getting the latest version of PHP installed onto IIS, I then proceeded to follow the admittedly-easy to follow installation steps for the most recent version of Laravel (which I believe is 5.2 as of this writing) via Composer. This, too, went fairly smoothly.
We Need Error Messages!
Now, I remembered from previous encounters with PHP and IIS that I had to turn on the detailed error messaging options for IIS in addition to ensuring that the php.ini file in use had "display_errors" turned on. No one likes to debug 500-type errors without feedback.
After verifying that IIS running a page containing raw PHP with a parsing error would, in fact, display a proper useful error, I then turned to a basic Laravel project with a similar parsing error to be certain I could also see a proper error being generated.
Wouldn't you know it? The "detailed" error page—while it did show some module information and error codes—did not show me the simple PHP error I was looking for.
It would seem that, given that IIS properly displayed the parsing error on the raw PHP form but not when running the Laravel application, the Laravel application/framework itself was swallowing the error!
After temporarily updating my web.config file to allow errors to pass through from PHP directly to the end user, I could see that no information from Laravel/PHP was making it through other than the error code, i.e. 500. My suspicions were more or less confirmed.
My travels eventually led me to the answer: In the .env file (that contains the Laravel environment options, naturally), I needed to add the following line:
APP_LOG = errorlog
I then refreshed my Laravel application in my browser and, lo and behold, proper PHP error messages started to appear—along with stack traces and additional information furnished by Laravel, thereby completely confirming my hypothesis.
I will admit to being a little surprised given that I had left the default values for the .env file alone without changing so much as a line, but these things happen.
Hopefully, this little tidbit will save others some headache.
Opinions expressed by DZone contributors are their own.