Buy
Buy

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!

  • 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?