3

Whenever I create an error (for example, changing

if (!file_exists($mageFilename)) in the index.php file to if (!fejfeA_frege(jskfnjs)fdsf)), it should display a Magento error report like this:

enter image description here

But instead of that, it shows a blank page. The network status is 500, but somewhere in my installation, something goes wrong and it won't show me the error report page.

My goal is to customise the frontend of the error report, but I obviously can't do that when I can't get the error report to show up.

UPDATE
It doesn't show a blank page anymore, but now it shows a white page with plain black text, after placing this snippet in the index.php file:

ini_set('error_reporting', E_ERROR);
register_shutdown_function("fatal_handler");
function fatal_handler() {
    $error = error_get_last();
    echo("<pre>");
    print_r($error);
}

And it results in this error (I placed an 'x' in the bootstrap.php file in order to create the error):

Array
(
    [type] => 4
    [message] => syntax error, unexpected end of file
    [file] => /[DOMAIN]/public_html/app/bootstrap.php
    [line] => 34
)
5
  • Check Magento's exception.log or Apache's error.log and update your question accordingly. Commented Dec 19, 2016 at 13:12
  • @JulienLachal I am not very experienced with the backend system of Magento, and my exception.log is saying that my access to the database is denied. I have no idea what it means :/ Commented Dec 19, 2016 at 13:16
  • put ini_set('display_errors', 1); at the top of index.php. what exactly is the error you find in exception.log? check if you can connect to the database with credentials you find in app/etc/local.xml
    – goivvy.com
    Commented Dec 19, 2016 at 13:40
  • check app/etc/local.xml to see if your DB credentials are correct Commented Dec 19, 2016 at 13:45
  • Adding ini_set('display_errors', 1); to index.php quickly displayed actual error, spent hours trying to understand why I was getting a white/blank page after enabling UB Mega Menu extension. Apparently I missed mobile detect lib which is a pre-requisite for newer version.
    – cnu
    Commented Mar 8, 2021 at 3:02

1 Answer 1

2

The problem here is how errors work in PHP. PHP knows different types of errors:

  • warnings: these are logged or displayed, depending on the setting, but the script continues to run. There are different levels (notices, deprecation warnings, strict notices, warnings). You can set up custom error handlers for these.
  • fatal errors: fatal errors let the script halt immediately. This includes parse errors (syntax errors). Custom error handlers do not apply, but shutdown functions still run.
  • exceptions: exceptions were introduced with PHP 5 as a new language feature. They can be catched and handled with try { } catch { } Uncatched exceptions result in a fatal error

Now what does Magento do?

  • a custom error handler logs warnings to system.log and, in developer mode, turns them into exceptions.
  • exceptions are logged to exception.log and the "There has been an error processing your request" page is shown. This page can be configured and themed in the errors directory of Magento.
  • for fatal errors, there is nothing Magento can do. This is where you get the dreaded white page, or if the error is triggered during template rendering, a half rendered page. Error logging is completely up to the web server (typical location: /var/log/apache2/error.log)

Unfortunately, a call to a non-existing function is a fatal error.

The good news is, in PHP 7 there will be less and less uncatchable fatal errors, since errors now can be catched like exceptions as well. But this will only work if Magento changes catch (Exception) to catch (Throwable). More info: http://php.net/manual/en/language.errors.php7.php

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.