This tutorial has a new version, check it out!

Leveraging the prod Environment

Keep on Learning!

If you liked what you've learned so far, dive in!
Subscribe to get access to this tutorial plus
video, code and script downloads.

Start your All-Access Pass
Buy just this tutorial for $10.00

With a Subscription, click any sentence in the script to jump to that part of the video!

Login Subscribe

Right now, our app is in the dev environment. How can we change it to prod? Just open .env and set APP_ENV to prod!

# .env

# ...
APP_ENV=prod
# ...

Then... refresh!

This page may or may not work for you. One big difference between the dev and prod environments is that in the prod environment, the internal Symfony cache is not automatically rebuilt. That's because the prod environment is wired for speed.

In practice, this means that whenever you want to switch to the prod environment... like when deploying... you need to run a command:

./bin/console cache:clear

The bin/console file also reads the .env file, so it knows we're in the prod environment.

And now when we refresh, it should definitely work. And check it out! There's no web debug toolbar. And if you go to a fake page, you get a very boring error page. And yea, you can totally customize this: just Google for "Symfony error pages": it's really easy. The point is, this is not a big development exception page anymore.

Click back into our article, and then go find its template: show.html.twig. Let's change the 3 hours ago to 4 hours ago:

... lines 1 - 4
{% block body %}
<div class="container">
<div class="row">
<div class="col-sm-12">
<div class="show-article-container p-3 mt-4">
<div class="row">
<div class="col-sm-12">
... line 13
<div class="show-article-title-container d-inline-block pl-3 align-middle">
... lines 15 - 17
<span class="pl-2 article-details"> 4 hours ago</span>
... lines 19 - 22
</div>
</div>
</div>
... lines 26 - 71
</div>
</div>
</div>
</div>
{% endblock %}
... lines 78 - 83

Move back to your browser and refresh! Yep! The page did not update! That's the behavior I was talking about.

To make it update, find your terminal and run:

./bin/console cache:clear

The dev and prod Cache Directories

Oh, and check out the var/cache directory. Each environment has its own cache directory: dev and prod. When you run cache:clear, it basically just clears the directory and recreates a few files. But there is another command:

./bin/console cache:warmup

This goes a step further and creates all of the cache files that Symfony will ever need. By running this command when you deploy, the first requests will be much faster. Heck, you can even deploy to a read-only filesystem!

And now when you refresh... it works: 4 hours ago.

Changing the Cache in the dev Environment

Change the environment back to dev:

# .env

# ...
APP_ENV=dev
# ...

Here's our next challenge. In config/packages/framework.yaml, we configured the cache to use APCu:

framework:
... lines 2 - 16
cache:
... lines 18 - 28
# APCu (not recommended with heavy random-write workloads as memory fragmentation can cause perf issues)
app: cache.adapter.apcu

What if we did want to use this for production, but in the dev environment, we wanted to use the filesystem cache instead for simplicity. How could we do that?

We already know the answer! We just need to override this key inside the dev environment. Create a new file in config/packages/dev called framework.yaml... though technically, this could be called anything. We just need the same keys: framework, cache, app. Add those, but now set app to cache.adapter.filesystem, which was the original value:

framework:
cache:
app: cache.adapter.filesystem

Let's see if it worked! Open ArticleController and dump the $cache object so we can see what it looks like:

... lines 1 - 13
class ArticleController extends AbstractController
{
... lines 16 - 26
public function show($slug, MarkdownInterface $markdown, AdapterInterface $cache)
{
... lines 29 - 53
dump($cache);die;
... lines 55 - 67
}
... lines 69 - 80
}

And, refresh! Yes! It's using the FilesystemAdapter! What about the prod environment? In .env, change APP_ENV back to prod:

# .env

# ...
APP_ENV=prod
# ...

But don't forget to clear the cache:

./bin/console cache:clear

The warmup part is optional. Refresh! Yea! In the prod environment, the cache still uses APCu.

Change the environment back to dev:

# .env

# ...
APP_ENV=dev
# ...

In reality, you won't spend much time in the prod environment... it mostly exists for when you deploy to production.

Let's also remove the dump():

... lines 1 - 13
class ArticleController extends AbstractController
{
... lines 16 - 26
public function show($slug, MarkdownInterface $markdown, AdapterInterface $cache)
{
... lines 29 - 53
dump($cache);die;
... lines 55 - 67
}
... lines 69 - 80
}

Oh man, with environments behind us, we can jump into the heart of our tutorial.. the thing I have been waiting to do: create our own services.

Leave a comment!

  • 2020-05-04 Todor Vachkov

    Windows Version 10.0.18363.815; PHP CGI 7.3.14 (also tried with 7.4.5, the issue remains); Symfony CLI version 4.14.3; Symfony Framework 4.4.8; APCu v. 5.1.18

    I get server crashes on both - the Symfony CLI (since the Web Server Bundle is deprecated in Symfony 4.4) and the PHP's built-in Web Server after altering some twig template and then clearing the cache via cache:clear. When hitting again on page refresh the error comes out.

    I had to comment out apc.enable_cli=1 in my php.ini. Since then no more crashes.

  • 2020-02-17 yvon Huynh

    thank you Diego Aguiar I will study them !

  • 2020-02-14 Diego Aguiar

    Hey yvon Huynh

    I'm glad to hear that you managed to fix your problem. About caching, you first have to install Symfony's cache https://symfony.com/doc/cur... then, you have to select which adapter you want to use (https://symfony.com/doc/cur... if you just don't know, you can use the cache.adapter.filesystem, and then, you just have to configure a pool and use it in your code. Here you can find more info and examples of how to do it exactly https://symfony.com/doc/cur...

    Anyways, if you have more questions let us know! Cheers!

  • 2020-02-14 yvon Huynh

    Hello Diego Aguiar , I think the problem is solved with the presence of the .env file, stupid mistake. how to properly switch to Symfony cache though?thanks

  • 2020-02-04 weaverryan

    Hey Vlad!

    > I've been thinking about getting a Symfony certification.

    Woo! You should!

    > Do you plan on creating a course just for that?

    Yes, we've thought about this for awhile - and I'd like to do it... but we don't have it yet :/

    > What suggestions do you have to prepare for it and what courses do you recommend?

    I answered this question a few years ago (wow! Time flies!) - and other than the Symfony version involved, my answer is the same - https://symfonycasts.com/sc... - the only difference is that the book I reference is outdated now (I think). The exam is hard - so you really need to study very broadly. The exam topics - listed at the bottom of https://certification.symfo... - give you a very accurate indication of how many things are covered.

    I hope that helps! And happy studying - it's very rewarding to be on the other side.

    Cheers!

  • 2020-02-03 Vlad

    weaverryan I've been thinking about getting a Symfony certification. What suggestions do you have to prepare for it and what courses do you recommend? Do you plan on creating a course just for that? Thank you!

  • 2020-01-31 Diego Aguiar

    > I restarted the web server and all the odd behaviour was corrected
    Wow, really? It makes me think that Apache is caching the responses but I don't know, it's just a wild guess

    >Thank you all for your willingness to assist... You are doing great job with symfonycast
    You are welcome man!
    Cheers!

  • 2020-01-31 Wilfried DEUDJUI

    Hello Diego, Ryan. Finally fixed it. The production code was updated and as I said i even manually remove the prod cache folder. While trying to understand what whas going on, an idea just popped in my head: restart the web server, in my case apache

    I restarted the web server and all the odd behaviour was corrected... still not fully understand where was the link, but can now move futher...

    Thank you all for your willingness to assist... You are doing great job with symfonycast

  • 2020-01-31 Diego Aguiar

    Hey Wilfried DEUDJUI

    That's very odd. It makes me think two possibilities
    1) Your production code didn't get updated
    2) The production cache, for some reason, didn't get cleared

    Or, are you using a different cache mechanism in production?

  • 2020-01-30 Wilfried DEUDJUI

    Hi Ryan.

    This is how it behaves: I have the role ROLE_STAFF, that is allow to access the url matched by "path: ^/company/list". In the controller, I annoted the the action like this:

    /**
    * @Route("/company/list", name="list_company")
    * @IsGranted("ROLE_STAFF")
    */
    public function listCompany(): Response

    Previously, the role was ROLE_CHIEF_OF_SQUAD. After clearing the cache in prod, it still required the role ROLE_CHIEF_OF_SQUAD to grant access to the url instead of ROLE_STAFF...

    Below it the security.yml

    security:
    access_control:
    - { path: ^/company/list, roles: ROLE_STAFF, requires_channel: '%env(SECURE_SCHEME)%' }
    - { path: ^/login$, roles: IS_AUTHENTICATED_ANONYMOUSLY, requires_channel: '%env(SECURE_SCHEME)%' }
    role_hierarchy:
    ROLE_ACCOUNTANT: [ROLE_STAFF, ROLE_PAY_ECTN, ROLE_ACCOUNT_BALANCE]
    ROLE_CADET_SQUAD: [ROLE_STAFF, ROLE_LIST_ECTN, ROLE_SHOW_ECTN]
    ROLE_SQUAD: [ROLE_CADET_SQUAD, ROLE_ECTN_SQUAD]
    ROLE_CHIEF_OF_SQUAD: ROLE_SQUAD

    I have the same issue with easyadmin. I updated the config file but it does not refresh in prod...

  • 2020-01-30 weaverryan

    Hey Wilfried DEUDJUI!

    Hmm. Well, that should not happen :). The environments should behave identically once you've cleared the prod cache. What exactly is the "bad" behavior you're seeing in the prod environment? Is it that the user that has a role suddenly *cannot* access a URL (but they can in dev)? Can you post your security.yaml file?

    Cheers!

  • 2020-01-30 Wilfried DEUDJUI

    Thank you for this course. I am currently facing an issue: I updated my security.yml file to allow a role to access an url and it works perfectly in dev. But when I move the change to production, it does not work, I wonder why. I cleared the cache and warmed it up, but still not working. I even manually deleted the prod cache folder but no changes. Any idea on how I can make it work ?

  • 2020-01-28 Diego Aguiar

    Hey yvon Huynh

    First of all I want to say that DoctrineCacheBundle is deprecated and you should use Symfony cache instead. Now, to your problem. Do you get the same error locally? Try removing manually your cache and then install composer again and let me know what happened

    Cheers!

  • 2020-01-27 yvon Huynh

    Hi, I have a problem when deploying to prod environment on Centos server, I set APP_ENV=prod in .env file
    then I exported APP_ENV=prod as suggested in Symfony official documentation, then ran composer install (with or without --no-dev flag)
    in either cases when the system tries to clear cache I got this error:
    Uncaught Error: Class 'Doctrine\Bundle\DoctrineCacheBundle\DoctrineCacheBundle' not found
    It seems it is ignoring the prod environment

  • 2019-12-10 Diego Aguiar

    Hey maxii123

    Yea... you can't use bin/console server:run when in prod environment, unless you run it before changing environments but anyways, it's better to start getting used to use Symfony CLI

    Cheers!

  • 2019-12-10 maxii123

    I cant get it into prod mode. I tried adding APP_DEBUG=0 as documented below in my .env but that didnt work either.

    screen shots:-

    https://i.imgur.com/v9d9JWS...

    https://i.imgur.com/F4LnrFg...

    Anything else?

    EDIT: I quit my shell, restarted it, navigated to my directory and "echo $APP_ENV" now reports "prod" - ok promising. I removed the cache with brute force : rm -rf var/cache and then "warmed it up".

    And now:

    https://i.imgur.com/rJV3fHg...

    I'm flummoxed.

    EDIT EDIT:

    OK I solved it.

    Problem #1: using ZSH under debian buster I needed to move out of my project directory and back into it in order for the new value of APP_ENV to be picked up from the .env file.
    problem #2: ./bin/console server:run doesnt work for prod. The solution is symfony serve.

  • 2019-10-24 Diego Aguiar

    Hey @stephansav

    You can run the clear cache command specifying which environment you want by passing in the option --env=dev. Or, you can manually clear your cache by running rm -rf var/cache (standing at your project's root)

    I hope this helps. Cheers!

  • 2019-10-24 stephansav

    It seems that I am still in prod environment even if I put APP_ENV=dev in .env file because when I run ./bin/console cache:clear I have that: [OK] Cache for the "prod" environment (debug=false) was successfully cleared. So, there is a problem somewhere. PS: Sorry, for my first message it is: APP_ENV=dev.

  • 2019-10-24 stephansav

    When I run ./bin/console server:run with in the .env file, APP_ENV=env, I have this error even if the bundle is installed:

    There are no commands defined in the "server" namespace.

    You may be looking for a command provided by the "WebServerBundle" which is currently not instal
    led. Try running "composer require symfony/web-server-bundle --dev".

    How can I solve that?

  • 2019-06-05 Victor Bocharsky

    Hey Balint,

    Hm, are you at the latest version of Symfony and it's dependencies? Anyway, I'd recommend you to use Symfony client: https://symfony.com/download . Then with "symfony serve" command you could start the local web server, and it also brings you HTTPS on your local computer for free.

    Cheers!

  • 2019-06-05 Victor Bocharsky

    Hey Balint,

    I see this is a duplicate of: https://symfonycasts.com/sc... - let's follow the thread there.

    Cheers!

  • 2019-06-03 Diego Aguiar

    Hey @bBálint Csató

    That's odd. Can you double check that nothing on your system is setting the `APP_ENV` variable as Ryan said? Another thing you can try is to start the web server first and then change the `APP_ENV` var to "prod"

  • 2019-06-01 Bálint Csató

    Hi,
    I have got the same issue with php bin/console server:run. So the debugger come up at invalid routes and changing the content of a twig file is refreshed after manipulation on production env. If I start the php web server with: php -S localhost:8000 -t public than it works as it should be. What can be the difference doing this way?

  • 2019-06-01 Bálint Csató

    Hi,
    I have got the same issue with php bin/console server:run. So the debugger come up at invalid routes and changing the content of a twig file is refreshed after manipulation on production env. If I start the php web server with: php -S localhost:8000 -t public than it works as it should be. What can be the difference doing this way?

  • 2019-04-24 Diego Aguiar

    Hey Giacomo Balloccu

    Yes, you also have to install and enable APCu on your local machine, the installation depends on your OS but if you are an Ubuntu user like me, here is a guide: https://serverpilot.io/docs...

    Cheers!

  • 2019-04-24 Giacomo Balloccu

    Hi! Currently I have this problem, when I uncomment the line in framework (the one about cache apcu) when I try to load a page which uses the cache I get the error:

    apcu is disabled


    I have downloaded apcu service with: composer require symfony/polyfill-apcu

    Do I have to enable it somewhere?

  • 2019-04-05 Diego Aguiar

    Hey Jose Dario Guerrero Aragon

    Hmm, that's odd and makes me believe that you are actually hitting dev environment. Do you see the debug toolbar at the bottom of the page? Also you can check the logs inside "var/log{dev, prod}" just to see if there is something funny going on.

    Cheers!

  • 2019-04-04 Jose Dario Guerrero Aragon

    In prod environment, any change in show.html.twig is showing up in the browser, without clearing the cache. im using Symfony 4.2.4

  • 2019-03-10 stereomaik

    Yeah, that's kind of like cheating because from what I understand it *should* mean your debug is off even in dev environment - or am I wrong?
    Anyway all my tests show this is indeed the problem with the server itself, as someone wrote above. It just doesn't reload the debug. Should be no problem on other servers.

    **EDIT**
    Confirmed, tried with xampp, works as expected. Do not use bin/console server:run :)

  • 2019-02-21 Camille Seuvin

    Hi All,

    Here's how I solved the problem:

    1) you have to stop the server,

    2) add:
    APP_DEBUG=0
    in the .env,

    3) restart the server,
    then replace APP_ENV=dev
    by APP_ENV=prod in the .env

    That's it

  • 2019-02-11 Vladimir Sadicov

    Pietrino Atzeni

    Yeah this is the limitation of server package. It doesn't reload env vars in runtime, only on start. If you want to test prod environment it's better to use standalone webserver like nginx or apache or new symfony binary which can be used for dev and prod testing.

    PS using symfony/web-server-bundle is not recommended for production

    Cheers!

  • 2019-02-07 Pietrino Atzeni

    I found the same issue, and I solved it in this way:
    1. I added the "server" package only in dev. I run the tutorial with "bin/console server:run".
    2. I changed the ".env" variable to "prod", and the change was indeed applied, but the server was still running in "debug" mode
    3. I tried to restart the server, but it wasn't available for "prod"
    4. I changed the "composer.json" and "bundles.php" to use the "server" package
    5. I restarted the server, and voilà!

  • 2019-02-04 weaverryan

    Hey payskin!

    Wow! Excellent research! So let's tack each thing on its own.

    First, about the apc.enable_cli part. What version of Symfony are you using? If it's the newest version, this smells a bit like a possible bug to me - could be a bug in Symfony with Windows + opcache or it could be a bug in opcache + PHP + Windows. I did find one other person with the same issue, but no more info :/ https://github.com/symfony/...

    Second, about the time changing when you refresh the page in prod, I also don't like this ;). First, to make sure I'm not misunderstanding, what "time" are you referring to on the page? Second, do you see the web debug toolbar on the page or not? Let me know and we can go from there :).

    Cheers!

  • 2019-02-02 payskin

    So, I'm through all the other oops mentioned in previous comments, and took some time experimenting a bit.

    The server crashing behavior is reproducible in Windows 10 (1809) with PHP 7.3.1, APCu 5.1.6 for Windows, Composer 1.8, Symfony 4.2.2 when apc.enable_cli=1 in php.ini.

    - Symfony server is started in dev environment
    - change APP_ENV to prod in .env
    - refresh page --> page works
    - clear cache --> [OK] Cache for the "prod" environment (debug=false) was successfully cleared.
    - refresh page --> localhost not responding,
    - check console --> server terminated unexpectedly

    Warming up the cache only, or clearing AND warming up the cache works. Clearing the cache only kills the server at next page refresh.

    Setting apc.enable_cli to 0 in php.ini makes clearing the cache safe.

    Here's another problem, not mentioned before:

    - server is running
    - APP_ENV set to prod,
    - not touching the cache just to make sure everything works :)
    - whenever I change the time in show.html.twig and refresh the page, the time changes in the page.

    So the page is somehow not being cached in prod. :-\

    Setting apc.enable_cli to 1 or 0 does not affect this behavior. Turning off apc in config/packages/cache.yaml does not help either. The page always updates even in prod.

    Any idea why? Might be a Windows thing.

  • 2019-01-25 Vladimir Sadicov

    Camille Seuvin

    maybe I'm missing something about your issue, but I see you have opcache enabled even in cli, it can cause issues some time, can you try to disable it and re-test everything.

    Cheers!

  • 2019-01-25 Camille Seuvin

    Thank you Vladimir Sadicov for your explanation.

    It's give nothing :
    https://app.box.com/s/cz60a...

  • 2019-01-24 Vladimir Sadicov

    Hey Camille Seuvin

    You should do it like
    mint@camille/var/www/html/perso/the_spacebar $ echo $APP_DEBUG
    Without using PHP, like terminal command

    Cheers!

  • 2019-01-24 Camille Seuvin

    mint@camille/var/www/html/perso/the_spacebar $ php -r 'echo $APP_DEBUG;'
    PHP Notice: Undefined variable: APP_DEBUG in Command line code on line 1
    mint@camille /var/www/html/perso/the_spacebar $ php -r 'echo $APP_ENV;'
    PHP Notice: Undefined variable: APP_ENV in Command line code on line 1

    I'm not sure if I run it well

  • 2019-01-23 weaverryan

    Hey Camille Seuvin!

    Thanks for the info. But, one last thing - when I said:


    echo $APP_ENV
    echo $APP_DEBUG

    I was unclear! I don't intend for that to be PHP code. I want you to run each of those as commands from your *terminal*. That will tell me if you possibly have some environment variables set. If they are not set, when you run these commands, it will print nothing out on the terminal. If there ARE values set, you will see those values. Also, what web server are you using?

    Cheers!

  • 2019-01-23 Camille Seuvin

    Hello @weaverryan

    Thank you for your reply

    2) Yes, by doing the previous test, I wrote "env" instead of "prod"

    B)

    string(4) "prod" string(1) "1"

    -------------------------
    Symfony
    ------------------------ -------------------------------------------------------------------------------
    Version 4.2.1
    End of maintenance 07/2019
    End of life 01/2020
    ------------------------ -------------------------------------------------------------------------------
    Kernel
    ------------------------ -------------------------------------------------------------------------------
    Type App\Kernel
    Environment prod
    Debug false
    Charset UTF-8
    Cache directory ./var/cache/prod (3.7 MiB)
    Log directory ./var/log (564 KiB)
    ------------------------ -------------------------------------------------------------------------------
    PHP
    ------------------------ -------------------------------------------------------------------------------
    Version 7.2.13-1+ubuntu16.04.1+deb.sury.org+1
    Architecture 64 bits
    Intl locale n/a
    Timezone Europe/Berlin (2019-01-23T12:23:06+01:00)
    OPcache true
    APCu true
    Xdebug false
    ------------------------ -------------------------------------------------------------------------------
    Environment (.env)
    ------------------------ -------------------------------------------------------------------------------
    SLACK_WEBHOOK_ENDPOINT https://hooks.slack.com/ser...
    APP_ENV prod
    APP_SECRET 027ec1964fe901e1375cadb459761550
    DATABASE_URL mysql://admin:admin@127.0.0.1:3306/the_spacebar
    MAILER_URL null://localhost
    ------------------------ -------------------------------------------------------------------------------

    Notice: Undefined variable: APP_ENV

    Thanks

  • 2019-01-22 weaverryan

    Hi Camille Seuvin!

    Sorry for my slow reply! I was traveling for a few days!

    So, a few interesting things:

    1) Your project has been started recently enough that it should be 100% up to date with all the latest ways of handling environment variables. So, we're all good there.

    2) In your output, it says APP_ENV env, which suggests that your APP_ENV variable in the .env file (or maybe .env.local file - you can configure these in either file) is set to the string env. This should be dev or prod. Do you see this in one of those files? Was this a temporary change?

    Sorry, I'll ask you to do (hopefully) two more things for me. Actually, you've done these before, but I want to see what the values are if you do them at the same time:

    A) Could you go into your index.php file and, right before the $kernel = line, add this:


    var_dump($_SERVER['APP_ENV'], $_SERVER['APP_DEBUG']);

    B) Once again run php bin/console about and print the output.

    What I'm trying to determine is if you might have APP_ENV or APP_DEBUG set as *real* environment variables somehow. Based on your last post, you have APP_ENV configured to the string env in one of your .env files. But, based on earlier posts, somehow $_SERVER['APP_ENV'] is the value prod. That suggests that you may have a real environment variable set. You can find that out by running this at the terminal:


    echo $APP_ENV
    echo $APP_DEBUG

    I'm sure we're close - how the environment variables are parsed is a fairly simple system - something just isn't lining up :).

    Cheers!

  • 2019-01-21 Timo

    weaverryan
    I don't know what code you expect me to post. The whole project? I started the videocasts from start end now I ended up at this lesson. So I started from scratch.

    I'm running Symfony 4.2.2 on a Vagrant environment.

    So I tried to run the project through the server component. And hey, it just works with the environment file. So I have to figure out why my vagrant is not working fine and the build in server is running fine.

  • 2019-01-15 Camille Seuvin

    Hey weaverryan , thanks for your reply.

    1)


    ------------------------ -------------------------------------------------------------------------------
    Symfony
    ------------------------ -------------------------------------------------------------------------------
    Version 4.2.1
    End of maintenance 07/2019
    End of life 01/2020
    ------------------------ -------------------------------------------------------------------------------
    Kernel
    ------------------------ -------------------------------------------------------------------------------
    Type App\Kernel
    Environment env
    Debug true
    Charset UTF-8
    Cache directory ./var/cache/env (1.0 MiB)
    Log directory ./var/log (388 KiB)
    ------------------------ -------------------------------------------------------------------------------
    PHP
    ------------------------ -------------------------------------------------------------------------------
    Version 7.2.13-1+ubuntu16.04.1+deb.sury.org+1
    Architecture 64 bits
    Intl locale n/a
    Timezone Europe/Berlin (2019-01-15T08:35:23+01:00)
    OPcache true
    APCu true
    Xdebug false
    ------------------------ -------------------------------------------------------------------------------
    Environment (.env)
    ------------------------ -------------------------------------------------------------------------------
    SLACK_WEBHOOK_ENDPOINT https://hooks.slack.com/services/TE0T4L6D6/BSDSK75SDR62/OS8BxksuZkqus
    APP_ENV env
    APP_SECRET 027ec1964fe901e1375cadb459761550
    DATABASE_URL mysql://admin:admin@127.0.0.1:3306/the_spacebar
    MAILER_URL null://localhost
    ------------------------ -------------------------------------------------------------------------------

    2) I Work on Linux Mint 18 Sarah 64-bit (on VM)

    Notice: Undefined variable: APP_ENV
    [Tue Jan 15 09:08:27 2019] 127.0.0.1:35988 [500]: /

    I use Symfony 4.2.1 , I started the project on december 30.

  • 2019-01-14 weaverryan

    Hey Timo!

    Ah, thanks for jumping in! So NOW I'm convinced that there is indeed some problem... somewhere. But, I can't repeat it yet :/. I've tried on a fresh Symfony 4.2 project and also using the exact code from this repository. In all cases, when I change to APP_ENV=prod in .env, then I am seeing "prod" and "false" for the APP_ENV and APP_DEBUG values.

    Could you possibly post the code that has the issue? Also, what version of Symfony are you using? And did you start it from scratch recently? Or is it an older project?

    Thanks for helping us debug this!

  • 2019-01-14 weaverryan

    Hey Camille Seuvin!

    Ah, ok! Now we are getting somewhere :). So, when APP_ENV=prod, this *should* make the APP_DEBUG value "0" (or false). For some reason, this is not happening in your case! What's even stranger is that the APP_DEBUG should be a boolean (true/false) - the string "1" is a bit odd also.

    So, we need to figure out what/why that APP_DEBUG flag is being set to "1". Let's try a few things:

    1) Run php bin/console about. At the bottom, you'll see an "Environment (.env)" section. Do you see APP_DEBUG or APP_ENV there? If so, what are their values?

    2) Assuming you are on Linux or Mac (but tell me if you are not), do you see any output when you run:


    echo $APP_ENV
    echo $APP_DEBUG

    Finally, what version of Symfony are you using? And did you start the project recently or is it an older project? Also, if you want, you can add debugging code into the config/bootstrap.php file (that file is responsible for "initializing" and reading the environment variables) to try to see what's going wrong.

    Cheers!

  • 2019-01-14 Timo

    Same issue here, only my output is different.

    I change the to `prod` but it shows 'dev'

    string 'dev' (length=3)
    string '1' (length=1)

    If I run cace:clear, it tells me:

    [OK] Cache for the "prod" environment (debug=false) was successfully cleared.

    If I dump the $_SERVER variable, it also dumps the APP_SECRET. If I change that variable in the .env file, I can see it changing.
    If I add a key to the .env file. It also shows me the key and the value can be changes.

    If I delete the key APP_ENV and clear the cache. It falls back to dev

    [OK] Cache for the "dev" environment (debug=true) was successfully cleared.
  • 2019-01-10 Camille Seuvin

    Hello, thanks for your replies.

    The dump :

    string(4) "prod" string(1) "1"

  • 2019-01-10 weaverryan

    Hey Camille Seuvin!

    Yep, this is super weird! So, let me give you some more information :). If you look at the index.php file, you'll notice *two* important environment variables being reference: APP_ENV and APP_DEBUG. You almost never worry about APP_DEBUG (which is a true/false value) because it's set automatically for you in the config/bootstrap.php file. Basically, if APP_ENV is prod, it's set to "false", otherwise it's set to true.

    I'm telling you this because it is actually the APP_DEBUG flag that controls whether or not the "debugging exception page" is shown (APP_DEBUG=true) or if the user-facing error page is shown (APP_DEBUG=false).

    Could you go into your index.php file and, right before the $kernel = line, add this:


    var_dump($_SERVER['APP_ENV'], $_SERVER['APP_DEBUG']);

    I'm especially interested in what APP_DEBUG is. I can't think of a reason why it would be behaving improperly - but this is the place to start :).

    Cheers!

  • 2019-01-09 Diego Aguiar

    I just can't spot the error, there must be something that I am missing, so it makes me think that it might be related to a Symfony4.2 change. I'll scale up this problem.

  • 2019-01-09 Camille Seuvin

    No, I don't :

    https://app.box.com/s/zf6od...

    PHP Configuration :
    7.2.13 -1+ubuntu16.04.1+deb.sury.org+1

    I Work on Linux Mint 18 Sarah 64-bit (on VM)

    Thanks

  • 2019-01-08 Diego Aguiar

    Hmmmm, something is not right. Have you modified "public/index.php" file? Can you show it to me?

  • 2019-01-08 Camille Seuvin

    Yes it is ! I double check and it's the same :
    http://recordit.co/RWvXontCtP
    (And I clean cache too)

  • 2019-01-07 Diego Aguiar

    That's weird. Can you double check that you are actually on prod environment?
    You can run bin/console and in the first line you can see which environment is being used

    If it says "prod", then, clear the cache bin/console cache:clear and try again

  • 2019-01-05 Camille Seuvin
  • 2019-01-04 Diego Aguiar

    Can you show me a screenshot of what you see?

  • 2019-01-04 Camille Seuvin

    Thanks Diego Aguiar for your reply, but I don't understand, I have to see the 404 error page (browser defaut 'oops..') but I see the error page of Symfony (in prod env)

  • 2019-01-03 Diego Aguiar

    Hey Camille Seuvin

    If you are on prod environment, then, yes, you won't see the debug toolbar, and you will see the error page templates instead of the error message with its stack trace

    Cheers!

  • 2019-01-03 Camille Seuvin

    Hello,
    When I try a fake page, a Symfony exception page was showed instead of the boring exception browser error.

    The Debug Toolbar didn't appear (it means I was in prod env)

    ###> symfony/framework-bundle ###
    APP_ENV=prod

  • 2018-12-21 Diego Aguiar

    Hey AbelardoLG

    I believe you haven't installed the server package yet and that's why you can't use any of its commands. Just run


    composer require symfony/web-server-bundle --dev

    (To use it you have to be in the "dev" environment)

    Cheers!

  • 2018-12-21 AbelardoLG

    I stopped the server since the refresh action didn't work: when I hit the Refresh button, a Symfony exception page was showed instead of the boring exception browser error.

    The Debug Toolbar didn't appear (it means I was in prod env) but Symfony page appeared instead.

    What's wrong? 🤔

  • 2018-12-21 AbelardoLG

    Hi everyone 🖖,

    Firstly, I changed the value of the variable

    APP_ENV to 'prod'.


    Secondly, I stopped the server and it was executed again:

    ./bin/console server:run


    Then, a message was showed:

    There are no commands defined in the "server" namespace.


    Finally, when I listed the commands from the console order, I didn't see the 'server' section; effectively, the error is right 😲.

    I am using Ubuntu 18.04 with Symfony 4.2: how could it be solved? 🤔

    Thanks in advance. 🤝 Best regards.

  • 2018-11-06 Maik Tizziani

    works for me too. thanks

  • 2018-11-05 weaverryan

    Hmm, no, I can't repeat it - even with apc.enable_cli set to 0. There must be something else relevant to the setup. Perhaps a Windows-only issue?

  • 2018-11-05 weaverryan

    Yo!

    Hmm, yea, it looks like something weird is indeed going on. apc.enable_cli=1 looks like a fix, but it shouldn't be happening... but somehow is! There was an old issue about this - but it was fixed a long time ago (Symfony 3.3) - https://github.com/symfony/.... It's possible there is another issue - I'll check into it and see if I can repeat things.

    Cheers!

  • 2018-11-05 Sawa

    I solved the error by removing "apc.enable_cli=1" in php.ini.

  • 2018-11-04 Maik Tizziani

    same problem here

    platform: win10, gitbash, php7.2(x86 from xampp)

    the error happens if i change env and than clear the cache. if not changing env and clearing cache all works fine.

    its not big to restart the server after crash, but not fine if it happens in company presentation ;)

  • 2018-09-11 Diego Aguiar

    Hey Sawa

    The server error is right, that's unexpected :)
    Try updating your composer to see if the error goes away

    composer update

    Cheers!

  • 2018-09-10 Sawa

    I have a problem on Windows : the server crash when i reload the page after a cache:clear

     
    Warning: Uncaught ErrorException: Warning: require(D:\the_spacebar\var\cache\dev\ContainerXretPH8\getConsole_ErrorListenerService.php): failed to open stream: No such file or directory in D:\the_spacebar\var\cache\dev\ContainerXretPH8\srcDevDebugProjectContainer.php:277
    Fatal error: ContainerXretPH8\srcDevDebugProjectContainer::load(): Failed opening required 'D:\the_spacebar\var\cache\dev\ContainerXretPH8\getConsole_ErrorListenerService.php' (include_path='.;C:\php\pear') in D:\the_spacebar\var\cache\dev\ContainerXretPH8\srcDevDebugProjectContainer.php on line 277
    Fatal Compile Error: ContainerXretPH8\srcDevDebugProjectContainer::load(): Failed opening required 'D:\the_spacebar\var\cache\dev\ContainerXretPH8\getConsole_ErrorListenerService.php' (include_path='.;C:\php\pear')

    Sometimes the server crash without error message (just [ERROR] Server terminated unexpectedly.) and i can see this in the logs :

     
    [2018-09-10 11:10:59] php.DEBUG: Warning: unlink(D:\the_spacebar\var\cache\de_/ContainerQmAgsdS.legacy): No such file or directory {"exception":"[object] (Symfony\\Component\\Debug\\Exception\\SilencedErrorContext: {\"severity\":2,\"file\":\"D:\\\\the_spacebar\\\\vendor\\\\symfony\\\\http-kernel\\\\Kernel.php\",\"line\":715,\"trace\":[{\"file\":\"D:\\\\the_spacebar\\\\vendor\\\\symfony\\\\http-kernel\\\\Kernel.php\",\"line\":541,\"function\":\"dumpContainer\",\"class\":\"Symfony\\\\Component\\\\HttpKernel\\\\Kernel\",\"type\":\"->\"}],\"count\":1})"} []
    [2018-09-10 11:11:11] request.INFO: Matched route "article_show". {"route":"article_show","route_parameters":{"_route":"article_show","_controller":"App\\Controller\\ArticleController::show","slug":"why-asteroids-taste-like-bacon"},"request_uri":"http://localhost:8000/news/why-asteroids-taste-like-bacon","method":"GET"} []
    [2018-09-10 11:11:11] console.DEBUG: Command "server:run -vvv" exited with code "1" {"command":"server:run -vvv","code":1} []

  • 2018-09-04 Diego Aguiar

    Hey Nicolás González Flores

    Sorry for the late response. About the error "[ERROR] Server terminated unexpectedly.", can you run it passing "-vvv" so we can gather more info about the problem

    And about "There are no commands defined in the "server" namespace." that bundle is not meant to run in a prod environment, that's why it's only loaded for "dev" environmnet, but if what you want is to test something quickly, then you can do exactly what you did :)

    Cheers!

  • 2018-08-31 Nicolás González Flores

    Hello guys, I'm having the same problem. No matter in which environment I am, whenever I do cache:clear and refresh the page, the server hits me with a "[ERROR] Server terminated unexpectedly."

    I changed in the bundle.php the env of the WebServerBundle to "all" so I could get rid off the error "There are no commands defined in the "server" namespace." when starting the server. But Idk what to do to fix the other error.

    Any suggestions?

    Best

  • 2018-08-05 Mike

    Its a joy to follow the course, you make me super curious about the next video! :)

  • 2018-07-17 Diego Aguiar

    Haha, don't worry Raymond Dube :)

    If you ever forget to add the "--dev" part, you can always fix it yourself by moving the dependency from "require" to "require-dev" in your composer.json

    Cheers!

  • 2018-07-16 Raymond Dube

    I wish I had a better memory, but I forgot to reply to this 2 months ago.

    The problem, for me, was that during the install, the software recommends/suggests using --dev, but KnpU, correctly omits that portion, so we can do the proper dual environment testing.

    This doesn't mean we're using the server for actual production, just using the built in server to simulate, as best we can, the production environment.

    It's really all on me, following the course more closely, I should have seen the difference, but all's well that ends well. :)

  • 2018-07-16 Victor Bocharsky

    Hey guys,

    Do not confuse Composer's "require-dev" with Symfony's dev environment - they are different things. And do not confuse running Symfony web server vs loading website on the Symfony web server. I run Symfony web server in *dev* mode, but then I load the website on this server in dev (or prod, or even test) environment by access the proper front controller like http://localhost:8000/app_dev.php (or http://localhost:8000/app.php, or http://localhost:8000/app_test.php). So as you can see, even if you've run the server in Symfony dev mode, you can load your website in prod mode by going to a proper URL, i.e. http://localhost:8000/app.php - we're talking about different running kernels. It's like talking that if you load your website in the dev mode in one Chrome's tab, you can't load it in the prod mode in a different tab simultaneously - we're talking about different processes. I hope it's clearer to you now.

    Cheers!

  • 2018-07-14 ssdk86

    the same thing

  • 2018-05-25 Diego Aguiar

    Excellent, if you find something interesting, let us know and we will update our content (even if it's something related to windows)
    Cheers!

  • 2018-05-25 Raymond Dube

    You hit the nail on the head, --no-dev would work correctly. I think the video from the initial install should have noted something about that. I"ll have to take a look there later and maybe make a comment.

  • 2018-05-25 Diego Aguiar

    Setting up a production server is always a good training but, symfony's web server should work for you anyways. It doesn't care if you required it as a dev dependency because you already installed that dependency (you have to use the flag --no-dev in order to avoid installing dev dependencies when running composer install), probably there is something else in your configuration that is causing that weird behaviour.
    Try running 'bin/console cache:clear -e prod'

  • 2018-05-24 Raymond Dube

    Hi Diego,

    I understand that it's not meant for production, but unless you're working in a dev/prod environment, the steps used in the video don't work, at least not on windows. Clearing the cache resets the site to use production values, where, in most cases, the server may not be running with the same setup, which may, and did in my case, cause issues.

    I may decide to setup a production server for training purposes, even if it never sees the public eye. :)

  • 2018-05-23 Diego Aguiar

    Hey Raymond Dube

    That web server is not meant to be used for a production environment, where you may have big numbers of users and transactions, that's why it's recommended to require it as a dev dependency, and instead you can install "Apache", "Nginx" or any other web server that fits your needs.

    Cheers!

  • 2018-05-23 Raymond Dube

    If the server is 'required' using --dev (composer require symfony/web-server-bundle --dev) wouldn't mean it will not work when you switch to the prod'uction environment?

    I'm not sure if this is the case, but when I switch to prod, and clear the cache, the server stops unexpectedly. I would think that means I need to reuire the server bundle without the --dev.

    --edit--
    without clearing the cache, things to seem to work correctly. Of course this is an Windows environment, so all bets are off on behaviour.

  • 2018-05-05 Dominik Drapała

    Now i understand. Thank you!

  • 2018-05-01 Victor Bocharsky

    Hey Dominik,

    By design, dump() behaves a bit different in dev environment, it does not break your page, instead, it collects all the dumps and put them into Symfony dev toolbar. So page does not look broken. But for this some extra code is responsible, which is overhead in production, and actually, you don't have Symfony dev toolbar in production too. So if you dump something - it is showed immediately. But with die() you interrupts this dev behavior, and you see the dump immediately.

    Cheers!

  • 2018-05-01 Dominik Drapała

    I wonder why do i need to append dumps with die in dev environment in order to be able to see them on the web page? When i'm in dev environment dumps are printed even before doctype. When i switch back to production environment - they appears inside body section and they are visible without appending die instruction. Any clues?