symfony debug:true does what? - symfony

I've been searching symfony docs and SO for an explanation of what changing symfony's debug flag to true does exactly. I feel stupid for not finding it ... can anyone provide a link to the doc?

Read Working with environments for more informations about the debug.
You are right, the Symfony Documentation related to the Debug component will help for use it but not give detailed explanations about the features added to the environment.
If you use debug=true in your environment, you will get the debug-bar containig all informations related to your environment, and other features related to debug in a PHP framework.
I will list the main additional features added by enabling debug :
Toolbar added with all informations about requests, security, deprecations, translations, configuration, and errors in your current request.
Cache files are dynamically rebuilt on each request.
Enable debugging features in packages and third-party libraries based on debug (such as Twig dump)
Errors displaying are no longer managed by the debug, it's just configured in the front-controller (e.g. app_dev.php and app.php)
Informations coming from Configuration and environments
Symfony documentation is very vast and it's surely not the bigger part, but very important to know, I discover it too.

Related

Symfony 5 hanndle access for external tools (knpsnappy)

In a Symfony 5.x project I use knplabs/knp-snappy-bundle.
Having private data-folders for different users results in generating PDF-documents that require images from folders which are not publicly accessable.
When trying to generate a PDF-document with an image in such a folder knpsnappy runs into a 60 sec timeout. The Symfony log says
Guard authenticator does not support the request.
I assume something regarding the "external" tool knpsnappy calling from outside the application but from the same server but does not triggering any security definition I defined.
I am unsure on how to allow knpsnappy to access a specific route.
Maybe someone can lead me into the right direction...?
I was misslead.
The cause of the problem wasn't access rights but the way the img-pathes were defined.
knp snappy wont be able to render images with URL-routes.
I switched the pathes to be absolut server pathes and now it works.
Found the solution here:
KnpSnappyBundle and Symfony 3.4 : images and/or css cause timeout

Symfony 3.3 custom config file

I've very new to Symfony. Before I've used mostly Laravel.
Lets assume I have an API Key which I want to use here and there thru the project.
It doesn't feel right to store it as a class constant because I can't find any class to keep it in. And it seems pretty dumb to have it in various places thru the app as a string.
Normally using Laravel I would have used a config file specifically for this task.
However in symfony I can't seem to do the same(either that or my google-fu skills are pretty bad). If they are, a simple link to some documentation will do just fine.
So my question is: Where can I store various constants used thru the app?
I'm sorry, but I'm afraid your Google-fu skills let you down this time.
Symfony.com has an excellent article about Configuration: Configuration -
Symfony Best Practices
The common way to save configuration parameters is by using parameters.yml. It supports environment variables as of Symfony 3.2.
The best practice for Symfony 2.x and 3.x:
Define the infrastructure-related configuration options in the
app/config/parameters.yml file.
The best practice for Symfony 4:
Define the infrastructure-related configuration options as environment
variables. During development, use the .env file at the root of your
project to set these.

How can I get the Doctrine entity metadata before compiling Symfony container?

In one Symfony bundle I define a compiler pass to preprocess some configuration. Part of that config is based on Doctrine entities, so I need to get the full metadata information for all application entities.
The compiler pass is executed very late (PassConfig::TYPE_BEFORE_REMOVING). I'm using $container->get('doctrine') like this to get the entity metadata:
$em = $container->get('doctrine')->getManagerForClass($entityClass);
$entityMetadata = $em->getMetadataFactory()->getMetadataFor($entityClass);
However, this is causing random failures for some users because of the use of the doctrine service during the Symfony container compilation.
I'd recommend to change your entities addressing. Mainly - create your models with interfaces and make entities implementing them.
Using resolve_target_entities Doctrine will "convert" them to the particular classes.
An example code is here: https://github.com/Sylius/SyliusResourceBundle/blob/master/DependencyInjection/Compiler/DoctrineTargetEntitiesResolverPass.php
Just make sure your bundle is registered before DoctrineBundle is registered.
Then - in your whole app - instead of AppBundle::Entity addressing, use FQDN of interface bound to an entity earlier.
I've experimented a bit with compilers and services and it's a very bad idea to base on cross-bundle services under compiling container process... Why? It's not reliable - sometimes it will work as you want, sometimes it will fail as you described.
Thank you all for your comments and ideas. I post an answer to explain how I solved this problem.
Trying to use the Doctrine service in a compiler pass was creating more and more problems for our users (and it was creating other minor issues with other services such as Twig). So this was definitely a bad solution for our needs.
So at the end I decided to change everything. We no longer use a compiler pass to process the configuration and instead we use a regular PHP class called during runtime.
In the dev environment, the configuration is processed for each request. It's a bit slower than before, but we prevent any caching issue. In the prod environment we use Doctrine Cache to process the configuration once. Besides, we've create a cache warmer to create the cached configuration before the first request hits the application.

Best strategy for upgrading application from Symfony 2.0 to Symfony 2.4?

I need to upgrade an existing rather large application from Symfony 2.0.15 to Symfony 2.4.x (replace with current version).
I'm not quite sure what would be the best strategy to do so. Migration critical features like forms or esi are used, of course :)
Upgrade "step by step" from one major version to another (2.1, 2.2, 2.3, 2.4)
Upgrade directly from 2.0.x to 2.4
Do you have any tips / experience to share ? Would appreciate it :)
Thanks,
Stephan
Each new version comes with an update UPGRADE-2.x.md file containing all intructions to convert your application from the immediately previous version.
I had to do that on my project as well, and I found the step-by-step method more natural and easier to manage. Fact is, there is no file such file as UPGRADE-2.0-to-2.4.md that would help you out for a direct conversion to 2.4.
I shall first recommend to make sure that none of your code uses obsolete functionnalities of Symfony 2.0 (not sure if there are deprecated parts in this version, though), because these can be removed in ulterior versions and will not be included in the UPGRADE file.
If you have done indeep modifications of the core Symfony code, you may find that some undocumented modifications are needed. For instance, there is a custom error handler in my project, extending the Symfony error handler. Well, although it was not documented in the UPGRADE file, the signature of ErrorHandler::handle() was modified and needed to be updated in my custom handler.
Similarly, I had to modify some namespaces because files had been moved in the framework code.
The conversion is still ongoing and I'm currently experiencing a weird error I'm trying to get rid of: The 'request' scope on services registered on custom events generates errors in the logs.

What is the best way to debug production error templates?

I am trying to create pretty error pages for my application by following this cookbook article. Sometimes a bug slips in, which causes the application to return a single line: 503 Service Unavailable. It would make my life a whole lot easier if only I could see the underlying error or exception thrown. Switching over to the development environment doesn't help either as the error templates are only used in production.
I figured out that I needed to add TwigBundle to assetic's configuration to use javascript and css assets. Problems like this are really hard to debug in the production environment.
Setting the debug mode to true in my front controller doesn't help, since production error templates get replaced by development templates.
EDIT
Thanks to Mike Purcell I managed to retrieve the errors provided. I got
Uncaught exception 'Symfony\Component\Routing\Exception\ResourceNotFoundException' in /[snip]/app/cache/prod/appprodUrlMatcher.php:669
Turns out the framework should be handling the exception, but in the case of a possible error inside the error Twig template, it just decides to throw a 503 error.
How do I turn on error reporting for the production environment in a Symfony2 application?
I'm tired of guessing what's wrong and clearing the cache. What is the best way to debug Twig's error templates in production?
The best way to see what errors are being thrown in production is to configure Monolog to email the errors too you or alternatively to a file.
Have a look at the Symfony2 Cookbook on emailing logs http://symfony.com/doc/master/cookbook/logging/monolog_email.html
To make the error pages look nicer have a look at this cookbook entry on how to do that http://symfony.com/doc/master/cookbook/controller/error_pages.html
There are open source tools specifically built for error reporting like Sentry, which has a native Symfony client.
disclaimer: I work for Sentry

Resources