> Symfony 5 > Upgrading & What's New in Symfony 5!
Login to bookmark this video
Buy Access to Course
20.

Hunting the Final Deprecations

Share this awesome video!

|

Keep on Learning!

Start your All-Access Pass

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

Login Subscribe

How can we be sure all our deprecated code is gone? The easiest way to catch most things is to surf around your site to see if you can trigger any other deprecation logs. Except... if a deprecation happens on a form submit where you redirect after... or if it happens on an AJAX call... you're not going to see those on the web debug toolbar.

Checking Deprecated Logs Locally

Fortunately, deprecations are also logged to a file. At your terminal, run:

tail -f var/log/dev.log

Symfony writes a lot of stuff to this log file... including any deprecation warnings: "User Deprecated". Hit Ctrl+C to exit the "tail" mode and run this again, but this time "pipe" it to grep Deprecated:

tail -f var/log/dev.log | grep Deprecated

We're now watching the log file for any lines that contain Deprecated. Unfortunately, because of that annoying doctrine/persistence stuff, it does contain extra noise. But it'll still work. You could filter that out by adding another | grep -v persistence.

Anyways, now we can try out the site: like clicking into an article... or doing anything else you can think of, like going to an admin section /admin/comments. Oh, duh - I'm not logged in as an admin. You get the point: use your site, then go back and check out the deprecations.

Yikes! I probably should have added that | grep -v persistence to remove all the noise. But if you look closely... yea... every single one of these is from doctrine/persistence!

So as best as we can tell, our site is deprecation free. But! There are a few more things to check to be sure.

Command Deprecations

For example, if you have some custom console commands, they might trigger some deprecated code. Open a new terminal tab and run:

php bin/console

This app has two custom console commands. Let's run this article:stats command... it just prints out a fake table:

php bin/console article:stats foo

It worked perfectly. But if you go back to the logs and look closely... ah! A real deprecation warning!

ArticleStatsCommand::execute() return value should always be of the type int since Symfony 4.4, NULL returned.

Interesting. Let's open that command: src/Command/ArticleStatsCommand.php:

51 lines | src/Command/ArticleStatsCommand.php
// ... lines 1 - 11
class ArticleStatsCommand extends Command
{
protected static $defaultName = 'article:stats';
protected function configure()
{
// ... lines 18 - 22
}
protected function execute(InputInterface $input, OutputInterface $output)
{
// ... lines 27 - 48
}
}

Since Symfony 4.4, the execute() method of every command must return an integer. At the bottom, return 0:

53 lines | src/Command/ArticleStatsCommand.php
// ... lines 1 - 11
class ArticleStatsCommand extends Command
{
// ... lines 14 - 24
protected function execute(InputInterface $input, OutputInterface $output)
{
// ... lines 27 - 49
return 0;
}
}

This ends up being the "exit code" that the command returns when you run it. Zero means successful and pretty much anything else - like 1 - means that the command failed.

Copy the return and open the other command class. At the bottom of execute(), return 0:

65 lines | src/Command/AuthorWeeklyReportSendCommand.php
// ... lines 1 - 14
class AuthorWeeklyReportSendCommand extends Command
{
// ... lines 17 - 38
protected function execute(InputInterface $input, OutputInterface $output)
{
// ... lines 41 - 61
return 0;
}
}

And... let's make sure that we don't have any other return statements earlier. Nope, it looks good.

Production Deprecation Log

So we've surfed the site, checked the logs and run some console commands. Now are we sure that all the deprecated code is gone? Maybe? There are 2 final tricks.

First, as I mentioned earlier, at this point, I would deploy my code to production and watch the prod.deprecations.log file for any new entries... ignoring any doctrine/persistence stuff:

24 lines | config/packages/prod/monolog.yaml
monolog:
handlers:
// ... lines 3 - 15
deprecation:
type: stream
path: "%kernel.logs_dir%/%kernel.environment%.deprecations.log"
// ... lines 19 - 24

If nothing new is added, it's almost definitely safe to upgrade.

Deprecations in Tests

Another easy trick is to... run your tests! You... do have tests, right? Run:

php bin/phpunit

For me, it looks like it needs to download PHPUnit... and then... cool! This collects all the deprecations that were hit inside our tests and prints them when it's done. There are a lot of doctrine/persistence things... but that's it! There are no Symfony deprecations.

I am now willing to say that our app is ready for Symfony 5.0. So... let's upgrade next! Thanks to all our hard work, upgrading to a new major version of Symfony is just a Composer trick.