1

I am trying for quite some time now to disable the profiler in the test-environment. The only way it works is manually setting APP_ENV=test in file .env but I want to do this through the command line, not by editing a file.

Here's everything I tried:

  • I tried editing bin/console like described in Chris Brown's answer in this thread: Load different .env file with a Symfony 4 command (I also added the file .env.test, and according to xdebug it loads the appropriate file and runs through the appropriate code and also the variables $env and $debug get the appropriate value when I run the server with --env=test --no-debug)

  • I tried setting profiler: enabled: false like described in flu's answer in this thread: How to disable profiler in Symfony2 in production? (in config/packages/test/framework.yaml)

  • I tried setting the profiler line in bundles.php to

Symfony\Bundle\WebProfilerBundle\WebProfilerBundle::class => ['dev' => true],

and to

Symfony\Bundle\WebProfilerBundle\WebProfilerBundle::class => ['dev' => true, 'test' => false, 'test_cached' => false],

I tried those solutions separately and also all together, still the profiler keeps popping up. Does anybody have an idea?

EDIT: After applying Alister Bulman's answer the command gives me this:

#php bin/console -e test debug:config framework profiler

Current configuration for "framework.profiler"
==============================================

enabled: true
collect: false
only_exceptions: false
only_master_requests: false
dsn: 'file:%kernel.cache_dir%/profiler'

EDIT 2: Thanks to Jared Farrish I just found out the browser is receiving the website in "dev" mode although the server is started in test environment on cli. Obviously editing bin/console and public/index.php is not enough, they're not called when the server receives a request from the browser.

EDIT 3: So I found out the http request goes first to public/index.php, but whatever I do, I cannot seem to make anything available there which was defined in bin/console although the whole server is started there in the first place. Anyone an idea how this can be done?

code_gamer
  • 357
  • 5
  • 15
  • Have you run it as `bin/console ... --env=test`? This is how it's supposed to work. – Jared Farrish Oct 16 '19 at 14:13
  • Yes. I figured this is how it's supposed to work indeed, but the profiler just pops up nevertheless. – code_gamer Oct 16 '19 at 14:16
  • 2
    These refer to the Web Profiler, which should only run from http. Is it coming up somehow when you run your cli tests? – Jared Farrish Oct 16 '19 at 14:24
  • uhm... good question. I guess I don't have those right now, I am a Symfony beginner in my first project. My question was about the web profiler indeed. Any quick way of testing what you mean though? – code_gamer Oct 16 '19 at 14:38
  • I was confused by this too when I started Symfony; the `test` environment is a configuration for running unit tests and other (generally command line) operations. If you're trying to disable the profiler in web requests. look at the code in `web/app.php`. `bin/console` is analogous to `web/app.php` for the command line, so they both configure different front controllers. – Jared Farrish Oct 16 '19 at 14:41
  • I don't have any file `web/app.php`, I can find in my IDE (PHPStorm) `vendor/symfony/console/Application.php` and `vendor/symfony/framework-bundle/Application.php`. Oh so the "test" environment is only for unit-tests? – code_gamer Oct 16 '19 at 14:46
  • Whatever the frontend's front controller is; if you're seeing the web profiler in a browser, it's the first file that your server hands the request to. I'm on 3.4 and it was `web/app.php` and `web/app_dev.php`, generally, although that might be different under 4. – Jared Farrish Oct 16 '19 at 14:48
  • And yes, `test` here refers to unit or other test rigs. You can create your own environments, like `dev-no-profile` that disables profiling but keeps debug logging or something. Generally, though, there's something odd about what's being described. – Jared Farrish Oct 16 '19 at 14:48
  • yes, the first file the request goes to is `bin/console`. I stepped through that, even to all other called nested functions and I see nothing out of the ordinary, all commands, ect are executed correctly and also .env.test is read instead of .env when I execute the server with `--env=test --no-debug`. Nevertheless the web profiler is shown when I visit a site from the app. I find this very strange. – code_gamer Oct 16 '19 at 15:03
  • 1
    It sounds like you're telling the cli call to be test, but your app's web front controller has dev setup and it enables the profiler. If that last sentence refers to visiting the site in a browser. Changing the test environment setting and calling it from the command line won't affect the environment the web process uses. – Jared Farrish Oct 16 '19 at 15:10
  • Yes, I have the same feeling. But how is that possible? The server is started on cli, why would the browser receive a different environment? – code_gamer Oct 17 '19 at 14:13
  • 1
    They use different controllers (`bin/console` and `web/app.php` or whatever), which configure things differently. Also, generally a server like Apache is calling the server's web front controller; running the local PHP server is going to access the same front controller. The fact they're both within the proximity of a cli doesn't mean they share bootstraps. – Jared Farrish Oct 17 '19 at 14:15
  • Okay... so I have to find the other "entry point". I did the same to `public/index.php` as it had more or less the same code as `bin/console`, but still the same result. Good point though. It's pretty obvious what I see in the browser isn't the test environment. EDIT: And now I have confirmation of that fact, the profiler shows me following information: Profiler token 237de7 Environment dev Debug disabled – code_gamer Oct 17 '19 at 14:24
  • 1
    Yeah, you have session, user, router, etc., that you generally don't have on the cli. It's a different environment than commands on a cli. – Jared Farrish Oct 17 '19 at 14:29
  • So I found out where the request goes. Opposite to what I thought it **does** go to `public/index.php`. But there is not any relationship with the commands I provided by starting the server with `bin/console server:start`. The env stays dev, and I cannot change it (by command line). Even creating a global variable in `bin/console` does not make it's value available in `public/index.php`. But the whole server is started by `bin/console server:start` in the first place and in it, all values are corresponding to the parameters I started the server with in the first place. Any idea? – code_gamer Oct 18 '19 at 13:45

2 Answers2

4

The profile can be enabled, or disabled in the framework configuration.

> bin/console -e dev debug:config framework profiler

Current configuration for "framework.profiler"
==============================================
only_exceptions: false
enabled: true
collect: true
only_master_requests: false
dsn: 'file:%kernel.cache_dir%/profiler'

In a newly generated project, these are best set (for the test environment) in the config/packages/test/framework.yaml file.

framework:
    profiler: 
        enabled: false
        collect: false
        # optionally others

Documentation for the framework config (profiler, and the rest) is at https://symfony.com/doc/current/reference/configuration/framework.html#profiler

Alister Bulman
  • 34,482
  • 9
  • 71
  • 110
  • 1
    Thank you! Unfortunately though this did not solve my problem, the profiler still pops up. EDIT: That's weird, the command gives me php bin/console -e test debug:config framework profiler Current configuration for "framework.profiler" ============================================== enabled: true collect: false only_exceptions: false only_master_requests: false dsn: 'file:%kernel.cache_dir%/profiler' although I also specifically have enabled set to false. – code_gamer Oct 17 '19 at 14:14
0

I found it myself. What I did was use a functionality of php.ini which is called "auto_prepend_file" where you can specify a PHP file which gets executed automatically before the actual PHP content is executed. So in there I put a path to a file with following content:

<?php

$_ENV['APP_ENV'] = 'test';
$_ENV['APP_DEBUG'] = 0;
code_gamer
  • 357
  • 5
  • 15