I definitely support this one. Having recently experienced an issue with wanting to go through another middleware before binding (because my binding relied on the existence of the session), I definitely think this would be a great addition, which should also be no larger upgrade step than the move to the web middleware was. Well done @GrahamCampbell 👏

Another use case I have for this is if an ID scheme has changed, and we need to redirect old URIs to the new scheme, we'd want to do this before the binding throws an exception and we end up with a 404 page. Alternatively, we may want to just transform the ID to the new scheme internally, and then continue to the route binding as if nothing had happened.

Just to make sure I understand this correctly:

Let's say your bindings need auth to have run first. You'll have to remove the bindings middleware from the global web group, and add it everywhere you need it as a route middleware (after the auth one)?

I think that can get a little messy, no?

I think that can get a little messy, no?

Better than nothing. The main use case I see isn't for custom binding middleware per route, it's just to overwrite the whole thing a single time. That way, there is no mess.

@JosephSilber note the order of when bindings / auth happen is the same before / after this change.

For those wishing this was in 5.2 as well:

• Fork the framework.
• Check out the 5.2.35 tag (or whichever version you are currently using, I've done it with .35 though and do not know if it will work with older versions).
• Make a new branch, so you can keep receiving updates on the 5.2 branch. (I didn't do this, like a dummy, and now I have to go back through and do so.
• On your new branch: git cherry-pick 42b20c3
• Fix the merge conflicts with the tests. They are mostly whitespace, but the new middleware was also added to the tests.
• Commit and push up to your fork. (Optionally: tag your branch somewhere within the 5.2.* release line, but make sure it won't conflict with future releases. I used 5.2.35.1 since I was working with 5.2.35 already.)
• Add the following to your composer.json:

"repositories": [
    {
        "type": "vcs",
        "url": "https://github.com/<yourusername>/framework"
    }
],

• If you didn't tag your branch within the 5.2.* releases then you'll have to change your required version of laravel/framework to dev-<yourbranch>. Otherwise, skip this step.
• composer update
• Add the new middleware (\Illuminate\Routing\Middleware\SubstituteBindings::class) to your middleware groups. I put it in the web group, but if you use bindings in your APIs and/or don't use the web group, add it to whichever group you are using.

Not something I'd actually recommend @mikemand.

If you want this in 5.2, I'd actually recommend extending the classes in your code, not forking the framework. Always avoid forking stuff to load as dependencies at all costs.

Or, just upgrade to L5.3. It's not too bad, but beware the docs are not done, and we could break more stuff, so you'd need to keep a close watch on this repo for a few more weeks.

If you want this in 5.2, I'd actually recommend extending the classes in your code, not forking the framework. Always avoid forking stuff to load as dependencies at all costs.

How would you go about extending the Router and changing visibility of the methods from protected to public? I thought that was not possible with PHP?

Or, just upgrade to L5.3. It's not too bad, but beware the docs are not done, and we could break more stuff, so you'd need to keep a close watch on this repo for a few more weeks.

Exactly why I'm not updating just yet.

How would you go about extending the Router and changing visibility of the methods from protected to public? I thought that was not possible with PHP?

Is possible. Note that you'd have to extend the application class too.

I moved my apps over to 5.3 purely to so I could delete our custom code like this. I've had this middleware in my apps for months. Only moving it to the core now.

I may just be stupid, but this change seems to have broken the ability to test routes that use model binding: #16260