The problem and a workaround are described in this laracasts thread 8 years ago. This is still the case.
In short, this is what's happening:
User opens create route of any resource. StartSession middleware sets previous url on the session to this page.
Debugbar is rendered on the page and tries to load its assets, which are loaded through AssetController in debugbar. That causes previous url on the session to be replaced with debugbar assets path.
User submits the form, triggering a request to store route of the resource. Let's assume there is a validation going on and it produces a validation error.
Laravel handles the validation error and by default redirects the user to the previous url from the session. Which is usually the create route, however when debugbar is enabled, it is replaced with assets path resulting in an unexpected redirect to the latter.
It would be great if debugbar urls were somehow excluded from being set as previous url on the session. Not sure how to achieve that, though, maybe use ->withoutMiddleware('StartSession') for such routes?
Either way, I think this problem deserves to be documented, at least in the form of this issue, because it was rather puzzling to see such behaviour when debugbar is enabled.
The problem and a workaround are described in this laracasts thread 8 years ago. This is still the case.
In short, this is what's happening:
createroute of any resource.StartSessionmiddleware sets previous url on the session to this page.AssetControllerin debugbar. That causes previous url on the session to be replaced with debugbar assets path.storeroute of the resource. Let's assume there is a validation going on and it produces a validation error.createroute, however when debugbar is enabled, it is replaced with assets path resulting in an unexpected redirect to the latter.It would be great if debugbar urls were somehow excluded from being set as previous url on the session. Not sure how to achieve that, though, maybe use
->withoutMiddleware('StartSession')for such routes?Either way, I think this problem deserves to be documented, at least in the form of this issue, because it was rather puzzling to see such behaviour when debugbar is enabled.