Replies: 10 comments
-
|
Hey there, thanks for reporting this issue. We'll need more info and/or code to debug this further. Can you please create a repository with the command below, commit the code that reproduces the issue as one separate commit on the main/master branch and share the repository here? Please make sure that you have the latest version of the Laravel installer in order to run this command. Please also make sure you have both Git & the GitHub CLI tool properly set up. Do not amend and create a separate commit with your custom changes. After you've posted the repository, we'll try to reproduce the issue. Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
Please note that what I reported is not a bug but a deprecation warning. As I´ve mentioned in the report, doing a |
Beta Was this translation helpful? Give feedback.
-
|
We can only fix the issue if Our integration tests so far hasn't show this specific warning so we do need a reproduction repository if this indeed require changes to |
Beta Was this translation helpful? Give feedback.
-
|
Here is how to handle it: as per: |
Beta Was this translation helpful? Give feedback.
-
|
@Spir I´ve done it on all my projects. That’s the way to solve it, but Laravel/framework, in fact, does not trigger a deprecation warning—only some first- and third-party packages do. Thanks for posting it here, as it may help others 😉 |
Beta Was this translation helpful? Give feedback.
-
|
By the way if you want to check is a param exists you will have to do this: |
Beta Was this translation helpful? Give feedback.
-
Actually Laravel is not responsible for this. It's just a wrapper. I'm currious how this will be handled since it may do some breaking changes. Anyway I think the upgrade make the code more clear. request()->get('something') was too clueless where the data came from. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry for spamming but there deprecation notice doesn't really help to fix any bug: Do you have any idea how to get more details? |
Beta Was this translation helpful? Give feedback.
-
|
Hi @Spir , that deprecation warning only happens if the code doesn´t meet the new Symfony Request settings for the |
Beta Was this translation helpful? Give feedback.
-
|
For our situation converting from // Old
$request->get('some_key', 'default_value') // the "symfony way"to // New
$request->input('some_key', 'default_value') // the "Laravel way"was the best solution. We only cared about checking the request's query and POST body. Hope that helps someone 👍 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Laravel Version
10.40.2
PHP Version
8.3.1
Database Driver & Version
No response
Description
After the composer update,
laravel/framework"was updated to 12.40.2 and is now throwing a deprecation warningSince symfony/http-foundation 7.4: Request::get() is deprecated, use properties ->attributes, query or request directly instead. in /home/theproject/public_html/vendor/symfony/deprecation-contracts/function.php on line 25Steps To Reproduce
To reproduce:
composer updateand check that it updates to laravel/framework 12.40.2composer dump-autoloadRequest::get()->('something')or$request::get()->('something')orrequest()->get()->('something')and replace it with$request->somethingorrequest()->somethingand the deprecation warning no longer appears.EDIT/UPDATE (December 1, 2025)
Not a framework bug
After digging into a clean Laravel installation, this is not a Laravel/framework bug or issue. It´s in fact a Symfony deprecation for the
Requestmethods used. For people using packages or their own code, they shold review anyrequest()->get()or$request->get()code that need to be changed. Please refer to Symfony documentation at https://symfony.com/blog/new-in-symfony-7-4-request-class-improvementsBeta Was this translation helpful? Give feedback.
All reactions