Lumen-framework: Request->route($param) doesnt work

[leemason]

trying to access route parameters through the request object (ie in controller constructor) doesnt work.

calling route() without any arguments works fine and returns an array (which i assume comes from fast route) however trying to get a param returns fatal error "parameter method doesnt exist on none object)

agreed fastroute isnt going to be as feature full as the beefy symfony alternative, but this should either be fixed or documented as not allowed.

[GrahamCampbell]

Could you provide a short code example please?

[GrahamCampbell]

Also, note that we only support lumen 5.1, not 5.0.

[yaede7]

I also have this issue. Looking at the code it seems the Request->route() returns an array and not an instance of \Illuminate\Routing\Route as documented

This is the route function from Illuminate\Http\Request:

    /**
     * Get the route handling the request.
     *
     * @return \Illuminate\Routing\Route|null
     */
    public function route()
    {
        if (func_num_args() == 1) {
            return $this->route()->parameter(func_get_arg(0));
        } else {
            return call_user_func($this->getRouteResolver());
        }
    }

To access the route parameters I have done $request->route()[2][$param];

Not sure if this is suppose the return an instance of \Illuminate\Routing\Route or an array though.

[GrahamCampbell]

returns an array

Does it?

[GrahamCampbell]

This issue is unrelated to Lumen. I'll have a look at that laravel function.

[GrahamCampbell]

Check out https://github.com/laravel/framework/pull/9417

[alexw23]

:+1: on this issue

[alexw23]

All the documentation points to $request->route() returning an object, but it returns an array. Using Lumen (5.1.4) (Laravel Components 5.1.*)

array:3 [
  0 => 1
  1 => array:13 [
    "middleware" => array:2 [
      0 => "api.auth"
      ...
    ]
    ...
  ]
  2 => array:1 [
    "customerId" => "3"
  ]
]

$request->route()->setParameter('User', $user); returns Call to a member function setParameter() on array

[GrahamCampbell]

Yes, the docs are just wrong.

[GrahamCampbell]

The array replaces a route object.

[crishoj]

Also note that when a request is invoked from a Laravel\Lumen\Testing\TestCase using the $this->post(...) syntax, $request->route suddenly returns NULL.

This is due to $route being NULL in the following:

/**
 * Get the route handling the request.
 *
 * @param string|null $param
 *
 * @return object|string
 */
public function route($param = null)
{
    $route = call_user_func($this->getRouteResolver());

    if (is_null($route) || is_null($param)) {
        return $route;
    } else {
        return $route->parameter($param);
    }
}

[belohlavek]

I think this is still a problem, I'm trying to get a Route from $request->route(), which is supposed to return Route|object|string, but I'm getting an array :confused: :question:
For some context: I'm trying to use a middleware to change the controller used by a request.

[christianjul]

This is still a problem.

The Request class is assuming the Illuminate Routing package, but since Lumen is using another routing system the route('param') call fails with an error.

Either Laravel should support this scenario too, or Lumen should use it's own version of the request class.

I am very surprised to find this kind of internal inconsistency unresolved for so long.

[killermonk]

I've had multiple PRs rejected to fix this issue in a variety of ways. Have also received no feedback from the author as to any way they'd like it fixed.

There's a pretty simple workaround. I can't remember the exact code, but route() returns an array, and you can then index into that array to extract the parameter that you need.

There are several other things that work in laravel and are broken in lumen because of the array-based routing strategy.

[christianjul]

A pretty simple workaround can be done like this:

$route = $request->route();
$user_id = is_array($route) ? $route[2]['user_id'] : $route->parameter('user_id');

But it shouldn't be necessary for the client code to circumvent internal inconsistencies like this in the framework. These things occur of course, but the lack of will to fix it isn't a good sign.

[desyncr]

@christianjul Problem is if you have to rewrite params with an array it's not possible as you're updating a copy of it.

[christianjul]

@desyncr that is probably right. I don't know. Can't imagine any scenario where I would want to do that, so didn't consider it.

[daspecster]

@taylorotwell so this is currently a blocker for our project. I can't imagine that POST routes are broken for everyone or else this would be a much larger issue.

We were able to manually fix the issue per some of the suggestions above, but obviously we want to use composer with the official Lumen-framework repo/package.

Is it that we're just using this wrong or am I missing something else?

[daverdalas]

The issue still exists :(

[davidspiess]

@GrahamCampbell why is this issue closed?

[killermonk]

@davidspiess

Roughly 2 years ago I submitted PRs to Laravel and Lumen to fix the routing issue. The Laravel PR was rejected as "not the right project" and the Lumen PR was rejected because it was too big of a change to put in mid-release, or some such. My requests for assistance/guidance as to how to get a "correct" PR in to fix the issue were met with silence.

So, why was the issue closed? When it really comes down to it, I get the impression that it was because it isn't a high priority to get feature-complete routing functionality in Lumen. Even after 2 years since the original bugs and PRs were filed.

[curlymuse]

This is a blocker for a project of mine right now too. Not sure why it's closed.

[laurencei]

Sigh. Just copped this on my 5.4 -> 5.5 upgrade.

@killermonk - I found your PR here https://github.com/laravel/lumen-framework/pull/580

Can you resubmit this for the "master" branch (so it goes into Lumen 5.6 at least).

Unless anyone else has a better idea? @themsaid ?

I cant update to 5.5 now - I have to stay on 5.4 until this is resolved 😞

[killermonk]

@laurencei I updated the pull request to point at master instead of the release branch. Is that sufficient, or do you need a new PR?

[laurencei]

@killermonk - TBH it's not up to me. But the original PR is "closed" - so Taylor wont see it.

IMO the best bet is to open a new PR, link to this issue and the many others - and point it to master to be considered for 5.6.

[benjamincrozat]

Just had the same issue with a co-worker. Doing $request->route()[2]['parameter_name'] looks really ugly, but it works as a tmp workaround.

[gm-ghanover]

The problem is using the $request object as an array (eg - $request['parameter']) and trying to avoid exceptions on optional parameters (eg - isset($request['parameter']) or $request['parameter'] ?? 'default') causes an error in \Illuminate\Http\Request::offsetExists. This makes almost all safe ArrayAccess use of $request impossible. Without modifying vendor code, there is no work-around to use ArrayAccess, you have to use $request->get('parameter')

[jensdenies]

This issue is fixed in 5.7.

[driesvints]

@JacksonIV thanks for checking 👍

[4levels]

Hi @driesvints,

I'm using Lumen with Lighthouse and this issue is still blocking. I can see that the changes from the PR mentioned above are present in my local project (currently at version 5.7.11) but I'm still getting a similar fatal error when accessing the request object via its offsetGet method:

Call to a member function parameters() on array
in Illuminate\Http\Request.php line 624

624:             $this->all() + $this->route()->parameters(),

Am I missing something here?
cc: @spawnia @chrissm79

[driesvints]

@4levels that issue seems very specific with the said library. If you want to provide a fix for this which is BC with the way Lumen works, feel free to send in a PR.

[jensdenies]

@4levels @driesvints I think i know what’s causing this. I will take a look at this, when i have time.

[jensdenies]

@4levels @driesvints I've opened a PR to fix this.