@@eugene_kulik Thanks! :)

@@official.joymax Please watch theoretical part of this video: kzbin.info/www/bejne/jYureqhjo5eleLs It contains all the answers to your questions. :)

This route does not require a controller because it is automatically handled by LexikJWTAuthenticationBundle. You have some issue with settings.

@@tanyawebdev thank you, Tatiyana ;)

hi, how did you solved? i have the same issue

Maybe ther's something else on your project. Starting on a blank project with PHP8.3 & Symfony 7.1, and another older upgraded from7.1 to 7.2 it has ben working for me. I had to remove symfony/asset-mapper (so I can't use {{ asset('...') }} on templates ) but It's working for me...

тоесть автоматически айди не задаются? не понимаю зачем тогда все эти аннотации связей.

Validation errors in a Bootstrap modal window won't automatically appear the same way as on a regular page. This is due to the specific structure and styles of modal windows. Why? ✓ A Bootstrap modal window is a separate DOM element that overlays the main page content. ✓ Validation errors generated by Symfony are usually displayed next to the corresponding form fields on the page. ✓ Within the modal window, these elements might be hidden by other elements or styles.

@@tanyawebdev Thx for the info. I researched alot about this topic today and it looks like bypassing with ajax seems to be the only way, if you use modals. That's sad, I really like how easy it is for standard forms.

In Symfony, "argument resolver" and "value resolver" are typically used in different contexts. "Argument resolver" is applied in the context of handling controller arguments during the execution of a request, while "value resolver" might be used to resolve values in other scenarios, such as dependency injection. Thus, although both can perform a similar value resolution function, they are usually applied in different situations within Symfony.

@@tanyawebdev Спасибо! Хотелось бы посмотреть видео с Argument resolver.

@@solvex8304 This video is about Argument resolvers. There might be some confusion because I named the resolvers with the "ValueResolver" prefix. However, in Symfony, the term "value resolver" is commonly used for built-in argument resolvers. It follows a standard convention in Symfony, highlighting their main purpose - resolving values in the context of handling controller arguments.

​@@tanyawebdev Я имел ввиду, что иногда в методах контроллеров вижу что-то типа #[ValueResolver(TaskArgumentValueResolver::class)] Task $task или #[ValueResolver(UserIdArgumentValueResolver::class)] UserId $userId. Что это такое, для чего нужно?

@@solvex8304 Sorry for late reply! :) In the examples you provided annotations are used to explicitly define the resolvers that should be applied to specific method arguments in a Controller. What does it mean? Symfony has many built-in resolvers that can handle different types of arguments (e.g., Request, User, DateTime). The ValueResolver annotation allows you to override the default mechanism and specify exactly which resolver should be used for a particular argument. Why is it useful? ✓ Increased flexibility. You can create custom resolvers to handle non-standard arguments or implement complex value retrieval logic. ✓ Improved readability. Explicitly specifying resolvers makes the code more understandable and transparent. ✓ Decoupling of logic. Resolvers separate the value retrieval logic from the controller logic, making the code more modular and testable.

Thanks for your feedback. I'll keep this in mind.

Thanks for your feedback. I'll keep this in mind.

Have you been unable to figure out how to install Webpack Encore in Symfony? Why do you think the video is useless?

​@@tanyawebdevYou´ve made a whole Video for 1 single command ;D, so yes, this video is useless.

@@pashatyulnev8603 😅 Actually here the full video: kzbin.info/www/bejne/fHimlnt7jKqIf6ssi=Sg3YT5t69sRwwT0i Then I divided that video into parts to make it easier to find the answer to a specific question and made a playlist of small videos: kzbin.info/aero/PL-T7sjNqXMumJH8XPpY57rNr-5jV5S__Q&si=Y4pvzFJvTPJNvcNi So for the sake of one command, I didn’t make a video. :) But thanks anyway for your feedback!

Thank you for your question. There is nothing strange about it. It is simply a quick way to update the database structure. Of course, this does not negate the fact that migrations are a more reliable way to manage the database schema, especially in a multi-user environment.

@@tanyawebdev миграции это грубо говоря гит история для базы данных и в современной разработке без использования миграций разработчики могут вносить изменения в базу данных непосредственно , без учета версий или контроля. И никто не поймет кто в каком моменте грохнул базу!!! Такой подход как у тебя просто недопустим!

@@erkash88 While the main focus of my educational video was on Domain-Driven Design (DDD) and email functionality, I opted for schema:update:force to illustrate quick schema updates. However, in practical scenarios, Doctrine migrations are recommended for a more controlled and maintainable approach to database schema updates. If we are talking about projects in real life, where development is carried out by a team, then you are absolutely right. But in the context of this particular topic, I don't think it's that important. If you or someone who read this branch interested in migrations, please then watch my video about it: kzbin.info/www/bejne/pXPaZISfatesbKM But in any case thanks for your feedback!

Thanks for your feedback! I'll try to improve in the next video. :)