Hey @bagwaa!

Yeah, upgrading to at least 6.2 (although 6.4 is the only 6.x that's still supported) should be easy enough. Here's a nice guide for switching from sensio/framework-extra-bundle to native Symfony attributes.

Our Doctrine & Symfony 7 course is coming out soon and it will use the native attributes!

Nice! thanks for the reply :)

Hey @developer

I believe you cannot easily change the paramConverter error message, but that message is only seen when the app is in the dev environment. To customize what the end-user will actually see, please check this docs https://symfony.com/doc/current/controller/error_pages.html#example-404-error-template

Cheers!

Hey @t5810!

Ah, sorry for the trouble and the my glacially slow reply! Ok, so I see the issue - there was a bug between older version of Symfony and doctrine/annotations v2 (which is required by the sensio/framework-extra-bundle library). Anyways, the fix is to update one Symfony package:

composer up symfony/framework-bundle

That should fix the issue :). I'm running that on our course code right now so that the downloaded code works for everyone again without issues.

Cheers!

Hello, I had the same problem and when I ran composer up symfony/framework-bundle I have this new error :

Attempted to load class "Locale" from the global namespace.
Did you forget a "use" statement?

this is where it says the error is :

C:\Users\Fourt\Desktop\sites\mixedVinyl\vendor\symfony\translation\LocaleSwitcher.php:37

 `        $this->defaultLocale = $locale;    }    public function setLocale(string $locale): void    {        \Locale::setDefault($this->locale = $locale);        $this->requestContext?->setParameter('_locale', $locale);        foreach ($this->localeAwareServices as $service) {            $service->setLocale($locale);        } `

Hey @Ted

I believe you need to install the PHP intl extension. If you're in a Linux alike environment, you can install by running these commands
sudo apt-get update -y
sudo apt-get install -y php-intl

Cheers!

Hey Michael,

It depends, but as you see there are many good options, and mostly it's the matter of taste. Sometimes you can prefer some option more just because the solution is easier with it. So, just use that one you would like the most. If in your code, it's easier to check it from the entity that returned by the param converter - great, that's a good way I think. But if it's easier for you to write a custom query and this way looks cleaner for you - great, go for it :) No matter what way you choose, Symfony is flexible enough and allows you to throw 404 error yourself, so both ways are valid technically, depending on which one you like the most, or which one looks cleaner to you, to your specific code.

P.S. usually calling a repository method directly is more obvious, flexible, and straightforward than param converter that mostly used for a very simple fetch. But if you can write a nice code with param converter and throw a custom 404 or even 403 - I don't see any strong arguments against it ;)

Cheers!

Hey MaxiCom,

The @ syntax in the comments is called PHP annotations, they were pretty popular before the new PHP 8 attributes that starts with # like #[Route('/mix/new')]. So, it's a special syntax that is read by the Symfony system. And yeah, almost everything in Symfony are services ;) but basically those @ParamConverter is just an alternative way of configuration :)

Cheers!