Symfony oops an error occurred

Edit this page

Troubleshooting

How to access the Application Logs?

Display the application log file via:

Any log messages generated by the application is sent to this app file. This includes language errors such as PHP Errors, Warnings, and Notices, as well as uncaught exceptions.

It also contains your application logs if you log on stderr.

Because Platform.sh manages this file for you (preventing disks to get filled and using very fast local drives instead of slower network disk), we recommend that applications always output their log to stderr. For Monolog, check config/packages/prod/monolog.yaml:

If you log deprecations, don’t forget to log them on stderr as well.

Oops! An Error Occurred

This error message comes from your application and is generated by the default Symfony’s error template.

The server returned a «500 Internal Server Error»

If your application works locally but you see this message on Platform.sh it usually means you have a configuration error or missing a dependency.

To fix this issue you have to inspect application logs, the cause of the error is usually specified in the error message:

If the error happens on a non production environment or on the main environment of a non production project you can also enable Symfony’s dev/debug mode to inspect the cause of the error:

The server returned a «404 Not Found»

New Symfony applications comes without controllers by default. This means there’s no page to show as a homepage. When running your project locally you should have been welcomed with this page:

But with this page when running on Platform.sh:

This is because Platform.sh runs in production mode and as such Symfony shown a generic 404 error. To fix this, you will have to create your first Symfony page.

If you already created a custom page, check that all your files are committed, that you ran symfony deploy and it succeeded.

Troubleshooting

How to access the Application Logs?

Display the application log file via:

Any log messages generated by the application is sent to this app file. This includes language errors such as PHP Errors, Warnings, and Notices, as well as uncaught exceptions.

It also contains your application logs if you log on stderr .

Because Platform.sh manages this file for you (preventing disks to get filled and using very fast local drives instead of slower network disk), we recommend that applications always output their log to stderr . For Monolog, check config/packages/prod/monolog.yaml :

If you log deprecations, don’t forget to log them on stderr as well.

Oops! An Error Occurred

This error message comes from your application and is generated by the default Symfony’s error template.

The server returned a «500 Internal Server Error»

If your application works locally but you see this message on Platform.sh it usually means you have a configuration error or missing a dependency.

To fix this issue you have to inspect application logs, the cause of the error is usually specified in the error message:

If the error happens on a non production environment or on the main environment of a non production project you can also enable Symfony’s dev/debug mode to inspect the cause of the error:

The server returned a «404 Not Found»

New Symfony applications comes without controllers by default. This means there’s no page to show as a homepage. When running your project locally you should have been welcomed with this page:

But with this page when running on Platform.sh:

This is because Platform.sh runs in production mode and as such Symfony shown a generic 404 error. To fix this, you will have to create your first Symfony page.

If you already created a custom page, check that all your files are committed, that you ran symfony deploy and it succeeded.

Источник

Name already in use

symfony-cloud-docs / troubleshooting.rst

• Go to file T
• Go to line L
• Copy path
• Copy permalink

Copy raw contents

Copy raw contents

How to access the Application Logs?

Display the application log file via:

Any log messages generated by the application is sent to this app file. This includes language errors such as PHP Errors, Warnings, and Notices, as well as uncaught exceptions.

It also contains your application logs if you log on stderr .

Because Platform.sh manages this file for you (preventing disks to get filled and using very fast local drives instead of slower network disk), we recommend that applications always output their log to stderr . For Monolog, check config/packages/prod/monolog.yaml :

If you log deprecations, don’t forget to log them on stderr as well.

Oops! An Error Occurred

This error message comes from your application and is generated by the default Symfony’s error template.

The server returned a «500 Internal Server Error»

If your application works locally but you see this message on Platform.sh it usually means you have a configuration error or missing a dependency.

To fix this issue you have to inspect application logs, the cause of the error is usually specified in the error message:

If the error happens on a non production environment or on the main environment of a non production project you can also enable Symfony’s dev/debug mode to inspect the cause of the error:

The server returned a «404 Not Found»

New Symfony applications comes without controllers by default. This means there’s no page to show as a homepage. When running your project locally you should have been welcomed with this page:

But with this page when running on Platform.sh:

This is because Platform.sh runs in production mode and as such Symfony shown a generic 404 error. To fix this, you will have to create your first Symfony page.

If you already created a custom page, check that all your files are committed, that you ran symfony deploy and it succeeded.

Источник

How to Customize Error Pages

Warning: You are browsing the documentation for Symfony 2.5, which is no longer maintained.

Read the updated version of this page for Symfony 6.2 (the current stable version).

How to Customize Error Pages

When an exception is thrown, the core HttpKernel class catches it and dispatches a kernel.exception event. This gives you the power to convert the exception into a Response in a few different ways.

The core TwigBundle sets up a listener for this event which will run a configurable (but otherwise arbitrary) controller to generate the response. The default controller used has a sensible way of picking one out of the available set of error templates.

Thus, error pages can be customized in different ways, depending on how much control you need:

Using the Default ExceptionController

By default, the showAction() method of the ExceptionController will be called when an exception occurs.

This controller will either display an exception or error page, depending on the setting of the kernel.debug flag. While exception pages give you a lot of helpful information during development, error pages are meant to be shown to the user in production.

Testing Error Pages during Development

You should not set kernel.debug to false in order to see your error pages during development. This will also stop Symfony from recompiling your twig templates, among other things.

The third-party WebfactoryExceptionsBundle provides a special test controller that allows you to display your custom error pages for arbitrary HTTP status codes even with kernel.debug set to true .

How the Template for the Error and Exception Pages Is Selected

The TwigBundle contains some default templates for error and exception pages in its Resources/views/Exception directory.

In a standard Symfony installation, the TwigBundle can be found at vendor/symfony/symfony/src/Symfony/Bundle/TwigBundle . In addition to the standard HTML error page, it also provides a default error page for many of the most common response formats, including JSON ( error.json.twig ), XML ( error.xml.twig ) and even JavaScript ( error.js.twig ), to name a few.

Here is how the ExceptionController will pick one of the available templates based on the HTTP status code and request format:

• For error pages, it first looks for a template for the given format and status code (like error404.json.twig );
• If that does not exist or apply, it looks for a general template for the given format (like error.json.twig or exception.json.twig );
• Finally, it ignores the format and falls back to the HTML template (like error.html.twig or exception.html.twig ).

If the exception being handled implements the HttpExceptionInterface, the getStatusCode() method will be called to obtain the HTTP status code to use. Otherwise, the status code will be «500».

Overriding or Adding Templates

To override these templates, simply rely on the standard method for overriding templates that live inside a bundle. For more information, see Creating and Using Templates.

For example, to override the default error template, create a new template located at app/Resources/TwigBundle/views/Exception/error.html.twig :

You must not use is_granted in your error pages (or layout used by your error pages), because the router runs before the firewall. If the router throws an exception (for instance, when the route does not match), then using is_granted will throw a further exception. You can use is_granted safely by saying <% if app.user and is_granted(‘. ‘) %>.

If you’re not familiar with Twig, don’t worry. Twig is a simple, powerful and optional templating engine that integrates with Symfony. For more information about Twig see Creating and Using Templates.

This works not only to replace the default templates, but also to add new ones.

For instance, create an app/Resources/TwigBundle/views/Exception/error404.html.twig template to display a special page for 404 (page not found) errors. Refer to the previous section for the order in which the ExceptionController tries different template names.

Often, the easiest way to customize an error page is to copy it from the TwigBundle into app/Resources/TwigBundle/views/Exception and then modify it.

The debug-friendly exception pages shown to the developer can even be customized in the same way by creating templates such as exception.html.twig for the standard HTML exception page or exception.json.twig for the JSON exception page.

Replacing the Default ExceptionController

If you need a little more flexibility beyond just overriding the template, then you can change the controller that renders the error page. For example, you might need to pass some additional variables into your template.

Make sure you don’t lose the exception pages that render the helpful error messages during development.

To do this, simply create a new controller and set the twig.exception_controller option to point to it.

You can also set up your controller as a service.

The default value of twig.controller.exception:showAction refers to the showAction method of the ExceptionController described previously, which is registered in the DIC as the twig.controller.exception service.

Your controller will be passed two parameters: exception , which is a FlattenException instance created from the exception being handled, and logger , an instance of DebugLoggerInterface (which may be null ).

The Request that will be dispatched to your controller is created in the ExceptionListener. This event listener is set up by the TwigBundle.

You can, of course, also extend the previously described ExceptionController. In that case, you might want to override one or both of the showAction and findTemplate methods. The latter one locates the template to be used.

As of writing, the ExceptionController is not part of the Symfony API, so be aware that it might change in following releases.

Working with the kernel.exception Event

As mentioned in the beginning, the kernel.exception event is dispatched whenever the Symfony Kernel needs to handle an exception. For more information on that, see Internals.

Working with this event is actually much more powerful than what has been explained before but also requires a thorough understanding of Symfony internals.

To give one example, assume your application throws specialized exceptions with a particular meaning to your domain.

In that case, all the default ExceptionListener and ExceptionController could do for you was trying to figure out the right HTTP status code and display your nice-looking error page.

Writing your own event listener for the kernel.exception event allows you to have a closer look at the exception and take different actions depending on it. Those actions might include logging the exception, redirecting the user to another page or rendering specialized error pages.

If your listener calls setResponse() on the GetResponseForExceptionEvent, event propagation will be stopped and the response will be sent to the client.

This approach allows you to create centralized and layered error handling: Instead of catching (and handling) the same exceptions in various controllers again and again, you can have just one (or several) listeners deal with them.

To see an example, have a look at the ExceptionListener in the Security Component.

It handles various security-related exceptions that are thrown in your application (like AccessDeniedException) and takes measures like redirecting the user to the login page, logging them out and other things.

Источник

How to customize Error Pages

Warning: You are browsing the documentation for Symfony 2.1, which is no longer maintained.

Read the updated version of this page for Symfony 6.2 (the current stable version).

How to customize Error Pages

When any exception is thrown in Symfony2, the exception is caught inside the Kernel class and eventually forwarded to a special controller, TwigBundle:Exception:show for handling. This controller, which lives inside the core TwigBundle , determines which error template to display and the status code that should be set for the given exception.

Error pages can be customized in two different ways, depending on how much control you need:

1. Customize the error templates of the different error pages (explained below);
2. Replace the default exception controller TwigBundle:Exception:show with your own controller and handle it however you want (see exception_controller in the Twig reference);

The customization of exception handling is actually much more powerful than what’s written here. An internal event, kernel.exception , is thrown which allows complete control over exception handling. For more information, see Internals.

All of the error templates live inside TwigBundle . To override the templates, simply rely on the standard method for overriding templates that live inside a bundle. For more information, see Creating and using Templates.

For example, to override the default error template that’s shown to the end-user, create a new template located at app/Resources/TwigBundle/views/Exception/error.html.twig :

You must not use is_granted in your error pages (or layout used by your error pages), because the router runs before the firewall. If the router throws an exception (for instance, when the route does not match), then using is_granted will throw a further exception. You can use is_granted safely by saying <% if app.user and is_granted(‘. ‘) %>.

If you’re not familiar with Twig, don’t worry. Twig is a simple, powerful and optional templating engine that integrates with Symfony2 . For more information about Twig see Creating and using Templates.

In addition to the standard HTML error page, Symfony provides a default error page for many of the most common response formats, including JSON ( error.json.twig ), XML ( error.xml.twig ) and even Javascript ( error.js.twig ), to name a few. To override any of these templates, just create a new file with the same name in the app/Resources/TwigBundle/views/Exception directory. This is the standard way of overriding any template that lives inside a bundle.

Customizing the 404 Page and other Error Pages

You can also customize specific error templates according to the HTTP status code. For instance, create a app/Resources/TwigBundle/views/Exception/error404.html.twig template to display a special page for 404 (page not found) errors.

Symfony uses the following algorithm to determine which template to use:

• First, it looks for a template for the given format and status code (like error404.json.twig );
• If it does not exist, it looks for a template for the given format (like error.json.twig );
• If it does not exist, it falls back to the HTML template (like error.html.twig ).

To see the full list of default error templates, see the Resources/views/Exception directory of the TwigBundle . In a standard Symfony2 installation, the TwigBundle can be found at vendor/symfony/symfony/src/Symfony/Bundle/TwigBundle . Often, the easiest way to customize an error page is to copy it from the TwigBundle into app/Resources/TwigBundle/views/Exception and then modify it.

Источник

I run nginx+php-fpm for all my sites. Some are drupal, some are standalone, some use varnish, too. All works great.

I’m installing a 1st symfony2 site — no varnish, just nginx.

After installing symfony,

 ✔  Symfony 2.6.5 was successfully installed. Now you can:

I 1st check the php web-server

cd ./symfony
php app/console server:run

@ nav to:

http://127.0.0.1:8000

I see

==> "Symfony - Welcome"

& @ nav to:

http://127.0.0.1:8000/config.php

I see

==> "Your configuration looks good to run Symfony."

Next I switch to an nginx config.

Testing non-php

echo blah > web/test.txt

@ nav to:

https://symfony.lan/test.txt

I see

"blah"

Next, I added to web/config.php

...
if (!in_array(@$_SERVER['REMOTE_ADDR'], array(
    '127.0.0.1',
    '::1',
+    '192.168.1.10',
+    '2001:xxx:xxxx:xxx::10'  
))) {
    header('HTTP/1.0 403 Forbidden');
    exit('This script is only accessible from localhost.');
}
...

If I nav to:

https://symfony.lan/config.php

I get in the browser

==> "Symfony - Welcome"

But @ nav to just:

https://symfony.lan

I get in the browser

Oops! An Error Occurred
The server returned a "404 Not Found".
Something is broken. Please let us know what you were doing when this error occurred. We will fix it as soon as possible. Sorry for any inconvenience caused. 

and in my log

==> /var/log/nginx/symfony.access.log <==
2001:xxx:xxxx:xxx::10 - - [23/Mar/2015:07:38:04 -0700] GET / HTTP/1.1 "404" 288 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:36.0) Gecko/20100101 Firefox/36.0" "-"

For the nginx config I followed

http://wiki.nginx.org/Symfony

My nginx config is basically verbatim

server {
    server_name www.symfony.lan;
    return 301 $scheme://symfony.lan$request_uri;
}

server {
    server_name symfony.lan;
    listen [2001:xxx:xxxx:xxx::10]:80;
    listen 192.168.1.10:80;
    rewrite ^(.*) https://symfony.lan$1 permanent;
    break;
}

server {
    server_name symfony.lan;
    listen [2001:xxx:xxxx:xxx::10]:443 ssl spdy;
    listen 192.168.1.10:443 ssl spdy;

    root        /svr/www/symfony.lan/symfony/web;
    access_log  /var/log/nginx/symfony.access.log   main;
    error_log   /var/log/nginx/symfony.error.log    info;
    rewrite_log off;
    autoindex  on;

    ssl on;
    include ssl.conf;
    ssl_verify_client off;
    ssl_certificate "ssldir/symfony.lan.crt";
    ssl_trusted_certificate "ssldir/symfony.lan.crt";
    ssl_certificate_key "ssldir/symfony.lan.key";

    add_header Strict-Transport-Security "max-age=315360000; includeSubdomains";
    add_header X-Frame-Options DENY;

    rewrite ^/app.php/?(.*)$ /$1 permanent;

    location / {
        index app.php;
        try_files $uri @rewriteapp;
    }

    location @rewriteapp {
        rewrite ^(.*)$ /app.php/$1 last;
    }

    location ~ ^/(app|app_dev|config).php(/|$) {
        fastcgi_pass phpfpm;
        fastcgi_split_path_info ^(.+.php)(/.*)$;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param HTTPS on;
    }

}

although referenced as a possible fix in other posts, executing @ web root

php app/console cache:clear  --env=prod
php app/console cache:warmup --env=prod

fixes nothing here.

Is this a problem with Symony or Nginx, with my config or the apps?

What specifically do I need to change to get the 1st page working?