[4.0][BUG] Unable to prepare route for serialization.

Bug report

What I did

php artisan optimize

What happened

 LogicException

  Unable to prepare route [admin/category] for serialization. Another route has already been assigned name [admin.category.store].

  at C:\laragon\www\WTrans\vendor\laravel\framework\src\Illuminate\Routing\AbstractRouteCollection.php:206
    202|             $route->name($name = $this->generateRouteName());
    203|
    204|             $this->add($route);
    205|         } elseif (! is_null($symfonyRoutes->get($name))) {
  > 206|             throw new LogicException("Unable to prepare route [{$route->uri}] for serialization. Another route has already been assigned name [{$name}].");
    207|         }
    208|
    209|         $symfonyRoutes->add($name, $route->toSymfonyRoute());
    210|

  1   C:\laragon\www\WTrans\vendor\laravel\framework\src\Illuminate\Routing\AbstractRouteCollection.php:179
      Illuminate\Routing\AbstractRouteCollection::addToSymfonyRoutesCollection(Object(Symfony\Component\Routing\RouteCollection), Object(Illuminate\Routing\Route))

  2   C:\laragon\www\WTrans\vendor\laravel\framework\src\Illuminate\Routing\RouteCollection.php:246
      Illuminate\Routing\AbstractRouteCollection::toSymfonyRouteCollection()

Backpack, Laravel, PHP, DB version

### PHP VERSION:
PHP 7.4.2 (cli) (built: Jan 21 2020 17:52:43) ( ZTS Visual C++ 2017 x64 )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies

### LARAVEL VERSION:
v7.0.8@d71ba61d51aec79a0a0f907991ec215dc24b09d4

### BACKPACK VERSION:
4.0.49@986f5e69593eab33e567787e0c28efb6747cd7b5

[lotarbo]

@pxpm looks like this is new https://github.com/laravel/framework/blob/a85f93244ae46a6542409c4296da6764795be14d/src/Illuminate/Routing/AbstractRouteCollection.php#L199 in laravel 7

[pxpm]

As me and @tabacitu already suspected.

Dunno why now it’s complaining, we are just going to make sure we don’t use the route anywhere like #2525

@lotarbo indeed, I have also confirmed that removing the PUT route ends the problem.

I think it’s safe to remove because we are not using it, we use the POST one.

I will open a PR for it.

Thank you all for the input, it really helped to tackle this one down.