I'd also like to know if there is any benefit from doing this, or whether it's just cleaning up some stuff.
[5.0] Changes to Controller -- Illuminate\Routing\Controller removed
I just ran a composer update this morning and got this error message:
Class 'Illuminate\Routing\Controller' not found
As it turns out Taylor has been busy and changed the way Laravel deals with controllers (at least that is the idea I got).
Taylor wrote:
The only controller base class and controller dispatcher will be moved to a separate “legacy” composer package for 4.x upgrades. This will use the new illuminate.routing.disptacher custom container hook to register a custom dispatcher to provides backwards compatibility with those using the 4.x container base class.
But I'm not sure what this changes really means. Taylor is talking about POPO controllers, but I have no earthly idea what that means...
I got my controllers back up by removing the the 'base controller' that has been removed.
BTW, this is not a complaint ;)
I think it is related to Route Annotation but I'm not sure
I removed the reference to the base controller, ran optimize, dump-autoload etc, but still getting the following error when running php artisan:
{"error":{"type":"Symfony\\Component\\Debug\\Exception\\FatalErrorException","message":"Call to undefined method Illuminate\\Routing\\Router::controller()","file":"C:\\Users\\me\\code\\project\\app\\Http\\routes.php","line":45}}
Line 45 (the only controller-type route defined in my routes):
$router->controller('password', 'Auth\RemindersController');
Is support for controller removed?
@jehad that has been removed
So you have to write the routes yourself (for the time being)
$router->get('password/remind', [
'uses' => 'Auth\RemindersController@getRemind',
'as' => 'auth.remind'
]);
$router->get('password/reset', [
'uses' => 'Auth\RemindersController@getReset',
'as' => 'auth.remind.post'
]);
$router->post('password/remind', [
'uses' => 'Auth\RemindersController@postRemind',
'as' => 'auth.reset'
]);
$router->post('password/reset', [
'uses' => 'Auth\RemindersController@postReset',
'as' => 'auth.reset.post'
]);
Yeah, seems like it. Route:controller() was an anti-pattern anyway, I hope it won't be re-added. Thanks @MThomas for confirming.
I've just removed the dependency and it worked. The title of the commit is a bit misleading though. No "need" to use controllers indicates that you can still use it but it's your own choice.
Anyway, another bit of magic from Taylor.
However, route filters stopped working ...
POPO = Plain Old Php Object ;) So by not extending the Controller, it is more decoupled (eg. you could use this controller with any other framework). Combined with method dependancy injection, you just ask whatever you need and you will get it ;)
Filters will probably also be with annotations (or some other way, not sure).
That's the danger of riding the dev-versions ;)
Yeah, lately each day there will be a critical code update. Hard to keep track!
Hi all,
Im getting the same issue, just ran composer update on a L5 application
Class 'Illuminate\Routing\Controller' not found
Can someone provide exact instructions on what is required for me to fix it, the discussion above is a bit over my head :)
Thanks, Rowan
Ok just worked it out..
For anyone else who has the same problem at the beginning of your controller where you have
<?php namespace App\Http\Controllers;
use Illuminate\Routing\Controller;
class TsrController extends Controller{
Simply remove the 'extends Controller'
Hope that helps Cheers Rowan
With new update you do not extend to Controller anymore...
How do i update my project if i kept original .git?
@rowanwins you can also remove the use statement.
beforeFilter etc in the controller - what would you use for them now?
@alexhiggins I expect that you should use (in the docblocks) something like:
@Before('your-filter-name')
However, at this time this won't work (at least) for your own filters
Yowza, this is a particularly tough one to swallow. Definitely need to figure out how to get filters working again.
I'm getting a Call to a member function domain() on null error from vendor/laravel/framework/src/Illuminate/Routing/UrlGenerator.php. Have I broken something or is this a Laravel change causing this? Cheers.
Edit: nvm noob mistake.
I'm really hoping we aren't forced to use annotations for that functionality. If I remember correctly, there's no way to apply a filter to specific routes created via Route::resource() without using the controller.
@thepsion5 I attach filters to my resource controllers using route groups
Route::group(array('before' => 'myfilter'), function () {
Route::resource('resource', 'ResourceController');
});
You can also attach them with
Route::whenRegex('resource1|resource2', 'myfilter');
@Stolz you apply filter to all routes in given resource, not to a specific one like create!
@keevitaja, does not Route::when(...) covers that?
Sorry, i have not used Route::when()
Here comes the Middleware.
@Stolz - I need to attach filters to a single resource route, vs the entire group. For example, different authentication for show vs. store/update.
@thepsion5 - I just spent an hour on converting one resource controller/route, where I had the same problem, into a dull list of regular gets/puts in routes.php then attaching the filters selectively according to the late controller constructor with 'onlys' and 'excepts'. Didn't feel like a step forward, honestly, but the only option I could see to restore the original state. Minor upside: Route:list command now showing these filters. Plus, next thing to tackle: "middleware" (odd nomenclature imho) vs. "filters".
Taylor said there will be a legacy package that can be added through composer to bring back the old functionality if that's what you prefer over the annotations.
I wonder if this legacy package will be deprecated at some point or will it be there forever. I really do not like the idea of annotations!
Actually, I'm struggling much more with the notion of "middleware" - annotations comparably easy to work around for those not into them. My filters now doing nothing anymore while neatly registered in routes.php - transforming them into "route middleware" (...) the next thing to get my arms around. Oh well. On the legacy package, I'd expect this to buy people time so they can stage their L4>5 migration path before the next major release arrives - no less, no more.
I'm seriously regretting ever starting my new project with using 5.0. Tt's already live in production.
It seems like very composer update breaks my code. I'll google it link to laracast.
I'm just going to stop doing composer update until 5.0 is in beta.
@yadakhov I'm not 100% sure about this, but I think you can update your composer.json to reference a specific commit hash. That way your Laravel installation will be something approximating stable.
Please or to participate in this conversation.