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!

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