If you liked what you've learned so far, dive in!
Subscribe to get access to this tutorial plus
video, code and script downloads.
With a Subscription, click any sentence in the script to jump to that part of the video!
Login SubscribeRight 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
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.
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.
// composer.json
{
"require": {
"php": "^7.1.3",
"ext-iconv": "*",
"knplabs/knp-markdown-bundle": "^1.7", // 1.7.0
"nexylan/slack-bundle": "^2.0,<2.2.0", // v2.0.0
"php-http/guzzle6-adapter": "^1.1", // v1.1.1
"sensio/framework-extra-bundle": "^5.1", // v5.1.4
"symfony/asset": "^4.0", // v4.0.4
"symfony/console": "^4.0", // v4.0.14
"symfony/flex": "^1.0", // v1.9.10
"symfony/framework-bundle": "^4.0", // v4.0.14
"symfony/lts": "^4@dev", // dev-master
"symfony/twig-bundle": "^4.0", // v4.0.4
"symfony/web-server-bundle": "^4.0", // v4.0.4
"symfony/yaml": "^4.0" // v4.0.14
},
"require-dev": {
"easycorp/easy-log-handler": "^1.0.2", // v1.0.4
"symfony/debug-bundle": "^3.3|^4.0", // v4.0.4
"symfony/dotenv": "^4.0", // v4.0.14
"symfony/maker-bundle": "^1.0", // v1.0.2
"symfony/monolog-bundle": "^3.0", // v3.1.2
"symfony/phpunit-bridge": "^3.3|^4.0", // v4.0.4
"symfony/profiler-pack": "^1.0", // v1.0.3
"symfony/var-dumper": "^3.3|^4.0" // v4.0.4
}
}