WEBVTT

NOTE Created by CaptionSync from Automatic Sync Technologies www.automaticsync.com

00:00:01.086 --> 00:00:04.336 align:middle
Let's revisit deprecations as
these are important to fix.

00:00:04.606 --> 00:00:08.716 align:middle
As mentioned earlier, before you
can safely jump to Symfony 8.0,

00:00:08.966 --> 00:00:13.136 align:middle
you need to ensure you're running
deprecation-free Symfony 7.4.

00:00:13.626 --> 00:00:17.396 align:middle
This means that there should be zero
deprecations across your entire app.

00:00:18.186 --> 00:00:21.546 align:middle
We know we can find deprecations
in the Web Debug Toolbar, but...

00:00:21.696 --> 00:00:24.566 align:middle
this just shows the deprecations
for the current page...

00:00:24.836 --> 00:00:25.506 align:middle
None here...

00:00:25.886 --> 00:00:27.086 align:middle
but click on this starship.

00:00:27.436 --> 00:00:29.336 align:middle
This page does have a deprecation.

00:00:29.966 --> 00:00:32.436 align:middle
Let's explore the deprecation
panel in more detail.

00:00:32.916 --> 00:00:35.166 align:middle
Click the icon in the toolbar to open it.

00:00:35.886 --> 00:00:38.356 align:middle
This deprecation looks like
it's coming from Doctrine,

00:00:38.356 --> 00:00:41.266 align:middle
something about raw field value access...

00:00:41.756 --> 00:00:42.536 align:middle
But look at this!

00:00:42.686 --> 00:00:45.426 align:middle
A link to a pull request right in the message!

00:00:45.596 --> 00:00:47.186 align:middle
Very helpful, I love it!

00:00:47.776 --> 00:00:49.756 align:middle
Copy the link and paste it in your browser...

00:00:51.676 --> 00:00:56.536 align:middle
This is the Doctrine PR that modified some
behavior and triggered this deprecation.

00:00:57.126 --> 00:00:59.476 align:middle
It looks like it fixes some memory issues.

00:01:00.056 --> 00:01:03.196 align:middle
There's a huge discussion to help
give us more context if we want.

00:01:03.806 --> 00:01:04.906 align:middle
But how do we fix it?

00:01:05.366 --> 00:01:08.576 align:middle
In the PR description, there
is a migration path section.

00:01:09.116 --> 00:01:14.926 align:middle
The new behavior is opt-in, and can be
enabled by passing accessRawFieldValues:

00:01:14.926 --> 00:01:17.246 align:middle
true to the Criteria constructor.

00:01:17.906 --> 00:01:20.886 align:middle
Ok... how do we find where
our app needs this fix?

00:01:21.286 --> 00:01:23.326 align:middle
Deprecation panel to the rescue!

00:01:23.986 --> 00:01:26.596 align:middle
Click "show trace" under
the deprecation message.

00:01:26.936 --> 00:01:30.666 align:middle
This is the stack trace of how
your app got to this deprecation.

00:01:31.176 --> 00:01:34.936 align:middle
You read this from the top down
and can mostly ignore the lines

00:01:34.936 --> 00:01:36.636 align:middle
that aren't in your src directory.

00:01:37.306 --> 00:01:41.666 align:middle
The first line in our src directory is
likely what's triggering the deprecation.

00:01:42.186 --> 00:01:46.186 align:middle
In this case, it's StarshipPartRepository
line 23.

00:01:46.816 --> 00:01:51.006 align:middle
We can even expand this to see the actual
code that's triggering the deprecation.

00:01:51.406 --> 00:01:55.666 align:middle
Neat! Also in this panel is
this "show context" link.

00:01:56.116 --> 00:02:00.746 align:middle
This shows the actual exception that was thrown,
but this mostly shows the same information.

00:02:01.016 --> 00:02:01.746 align:middle
The message...

00:02:01.866 --> 00:02:03.386 align:middle
and the stack trace.

00:02:03.386 --> 00:02:05.536 align:middle
I usually only ever use the stack trace link.

00:02:05.536 --> 00:02:11.246 align:middle
So... to find all the deprecations with the
web debug toolbar, we'd have to locally go

00:02:11.246 --> 00:02:16.436 align:middle
to every page, every form submit,
every API endpoint, and so on.

00:02:16.786 --> 00:02:18.506 align:middle
That's not very efficient.

00:02:18.506 --> 00:02:21.616 align:middle
So, what's the better way to find deprecations?

00:02:22.216 --> 00:02:24.526 align:middle
There's two primary alternative ways.

00:02:24.526 --> 00:02:26.206 align:middle
First is your test suite.

00:02:26.206 --> 00:02:29.556 align:middle
PHPUnit can be configured to show deprecations.

00:02:30.056 --> 00:02:34.276 align:middle
But... unless you have 100% test
coverage, this won't catch everything.

00:02:34.726 --> 00:02:36.966 align:middle
Oh man, I don't even have tests in this app...

00:02:37.776 --> 00:02:40.766 align:middle
The final way is a surefire catch-all method.

00:02:41.276 --> 00:02:46.686 align:middle
You deploy your Symfony 7.4 app to production
for a while, a few weeks or a month.

00:02:46.686 --> 00:02:50.696 align:middle
During that time, you log all the
deprecations that are happening in production.

00:02:51.196 --> 00:02:54.846 align:middle
Remember, deprecations aren't
errors, so they won't break your app.

00:02:55.576 --> 00:02:58.376 align:middle
Either as they happen, or at
the end of the time period,

00:02:58.596 --> 00:03:01.436 align:middle
you review those logs and fix the deprecations.

00:03:02.046 --> 00:03:05.866 align:middle
Do this cycle a few times until you
have no more deprecations in production.

00:03:06.386 --> 00:03:09.296 align:middle
Now you're ready to safely
upgrade to Symfony 8.0.

00:03:09.296 --> 00:03:13.486 align:middle
Let's take a look at how logging
works and can be improved.

00:03:14.016 --> 00:03:17.266 align:middle
Open config/packages/monolog.yaml.

00:03:17.266 --> 00:03:21.226 align:middle
Scroll down to the deprecation
handler under the production config.

00:03:21.906 --> 00:03:25.566 align:middle
This handler writes just the
deprecations to the standard error stream.

00:03:26.156 --> 00:03:28.366 align:middle
Of course, you can customize
this to your liking.

00:03:28.366 --> 00:03:31.576 align:middle
Spamming my team's Slack
channel with them is my favorite!

00:03:32.316 --> 00:03:35.796 align:middle
Let's add this handler to our dev
environment so we can see it in action.

00:03:36.426 --> 00:03:40.556 align:middle
Copy the deprecation handler and
paste it in the when@dev section...

00:03:42.826 --> 00:03:45.146 align:middle
I don't want to stream these
to standard error here,

00:03:45.146 --> 00:03:48.486 align:middle
so copy the path from the
handler above and paste it here.

00:03:49.996 --> 00:03:55.916 align:middle
Suffix the file with deprecations.json: This
is already using the JSON formatter and using

00:03:55.916 --> 00:03:58.796 align:middle
that extension will help me
make it pretty in PhpStorm.

00:03:59.576 --> 00:04:02.526 align:middle
Back in our app, refresh the
page that causes the deprecation.

00:04:03.236 --> 00:04:05.016 align:middle
Now, open var/log...

00:04:07.696 --> 00:04:09.206 align:middle
Hmm, I don't see the file.

00:04:09.726 --> 00:04:11.776 align:middle
Maybe PhpStorm hasn't picked it up yet.

00:04:12.116 --> 00:04:13.206 align:middle
I'll reload from disk...

00:04:13.696 --> 00:04:14.586 align:middle
and there it is!

00:04:14.886 --> 00:04:17.096 align:middle
dev.deprecations.json.

00:04:17.616 --> 00:04:18.516 align:middle
Open that up.

00:04:18.516 --> 00:04:20.686 align:middle
I'll format the code to make it easier to read.

00:04:22.156 --> 00:04:25.566 align:middle
We see the same deprecation message
as we saw in the profiler panel...

00:04:25.916 --> 00:04:27.196 align:middle
and a bunch of other things...

00:04:27.576 --> 00:04:29.836 align:middle
but... it's missing the stack trace.

00:04:30.306 --> 00:04:33.526 align:middle
By default, it's hard to know where
the deprecation is being triggered.

00:04:34.116 --> 00:04:36.256 align:middle
Luckily, we can include the stack trace!

00:04:36.326 --> 00:04:39.076 align:middle
I'll clear this log file
so we have a fresh start.

00:04:39.776 --> 00:04:43.866 align:middle
Back in monolog.yaml, in our
dev deprecation handler config,

00:04:44.186 --> 00:04:48.906 align:middle
add include_stacktraces:
true: Refresh the page...

00:04:49.946 --> 00:04:50.976 align:middle
check the log file...

00:04:50.976 --> 00:04:52.156 align:middle
format it...

00:04:54.276 --> 00:04:55.056 align:middle
and there we go!

00:04:55.446 --> 00:04:58.306 align:middle
The stack trace looks just like
it did in the profiler panel.

00:04:58.796 --> 00:05:00.036 align:middle
And sure enough, we can see

00:05:00.036 --> 00:05:04.506 align:middle
that StarshipPartRepository line
23 is triggering the deprecation.

00:05:05.546 --> 00:05:07.266 align:middle
There's one thing I think
that's still missing...

00:05:07.596 --> 00:05:10.246 align:middle
It would be nice to know what URL triggered it.

00:05:10.766 --> 00:05:14.596 align:middle
This would help duplicating the
issue locally and confirming the fix.

00:05:15.096 --> 00:05:20.066 align:middle
Monolog has something called processors
that can add extra data to the log entries.

00:05:20.536 --> 00:05:24.716 align:middle
There's a bunch of built-in processors,
one to add authentication details,

00:05:24.966 --> 00:05:28.266 align:middle
console command details, and
additional debug information.

00:05:28.796 --> 00:05:31.406 align:middle
The one I want to enable is the WebProcessor.

00:05:31.826 --> 00:05:36.466 align:middle
This adds the request details,
like the URL, HTTP method, and IP.

00:05:37.256 --> 00:05:40.546 align:middle
The built-in processors aren't
registered as services by default,

00:05:40.736 --> 00:05:42.636 align:middle
but it's super easy to do it ourselves.

00:05:42.696 --> 00:05:44.496 align:middle
I'll clear this log file again.

00:05:45.366 --> 00:05:49.696 align:middle
Open config/services.yaml and
at the bottom, under services,

00:05:49.906 --> 00:05:55.276 align:middle
add monolog.processor.web
with the class WebProcessor.

00:05:55.666 --> 00:06:00.306 align:middle
Choose the one from the Monolog Bridge, as
it's ready to go with Symfony: That's it!

00:06:00.596 --> 00:06:04.646 align:middle
It's autowired and autoconfigured,
so we don't need to do anything else.

00:06:04.646 --> 00:06:05.766 align:middle
Refresh the page again...

00:06:06.666 --> 00:06:07.706 align:middle
check the log file...

00:06:07.706 --> 00:06:09.446 align:middle
format it...

00:06:10.496 --> 00:06:11.496 align:middle
and there we go!

00:06:11.726 --> 00:06:15.866 align:middle
We have the message, the stack trace,
and down at the bottom, under extra,

00:06:16.116 --> 00:06:19.306 align:middle
we have the URL, the IP, and the HTTP method.

00:06:19.886 --> 00:06:22.916 align:middle
Just modify our setup for
production in your apps and deploy.

00:06:22.916 --> 00:06:27.176 align:middle
Finding, duplicating, and fixing
deprecations will be a breeze!

00:06:27.986 --> 00:06:30.336 align:middle
Ok, now to actually fix this deprecation!

00:06:30.796 --> 00:06:34.436 align:middle
It was triggered in StarshipPartRepository
on line 23, right?

00:06:34.976 --> 00:06:35.676 align:middle
Open that up...

00:06:35.776 --> 00:06:37.096 align:middle
and find line 23...

00:06:37.626 --> 00:06:41.146 align:middle
Remember, we have to pass true
to the Criteria constructor.

00:06:41.906 --> 00:06:46.476 align:middle
This Criteria::create() isn't the real
constructor, but it's a named constructor.

00:06:46.926 --> 00:06:48.136 align:middle
When we jump to that method...

00:06:48.446 --> 00:06:52.006 align:middle
sure enough, it has the accessRawFieldValues
parameter...

00:06:52.426 --> 00:06:53.476 align:middle
but it's commented out.

00:06:53.896 --> 00:06:54.676 align:middle
What's up with that?!

00:06:55.386 --> 00:06:57.416 align:middle
It's part of the deprecation process.

00:06:57.696 --> 00:06:59.536 align:middle
They can't just add the new parameter.

00:06:59.796 --> 00:07:03.966 align:middle
This class and method aren't final, so
to maintain backwards compatibility,

00:07:04.086 --> 00:07:05.776 align:middle
they have to keep the current signature.

00:07:06.266 --> 00:07:10.776 align:middle
They comment out the new parameter and
trigger the deprecation if it's not passed.

00:07:11.126 --> 00:07:15.436 align:middle
This func_num_args() stuff is a way to
check if the new parameter was passed

00:07:15.586 --> 00:07:18.006 align:middle
without actually adding it
to the method signature.

00:07:18.786 --> 00:07:22.236 align:middle
The next major version of this
package will have the real parameter

00:07:22.236 --> 00:07:25.436 align:middle
in the method signature, and
the old way will be removed.

00:07:25.786 --> 00:07:28.066 align:middle
That's the last step of the deprecation cycle.

00:07:28.776 --> 00:07:30.266 align:middle
Enough talk, let's fix it!

00:07:30.736 --> 00:07:36.736 align:middle
Back in StarshipPartRepository, pass true
to Criteria::create(): Back to the browser.

00:07:37.246 --> 00:07:39.896 align:middle
When we refresh, this deprecation
should be gone...

00:07:40.736 --> 00:07:41.436 align:middle
And it is!

00:07:42.026 --> 00:07:44.236 align:middle
We're finally ready to move to Symfony 8!

00:07:44.526 --> 00:07:45.236 align:middle
That's next!